Date: Fri, 2 Feb 2007 12:19:57 +0100 From: Andre Albsmeier <Andre.Albsmeier@siemens.com> To: Mike Pritchard <mpp@mppsystems.com> Cc: cvs-src@freebsd.org, Mike Pritchard <mpp@freebsd.org>, src-committers@freebsd.org, cvs-all@freebsd.org, Bruce Evans <bde@zeta.org.au> Subject: Re: cvs commit: src/sys/ufs/ufs ufs_quota.c Message-ID: <20070202111957.GA57142@curry.mchp.siemens.de> In-Reply-To: <20070202010632.GA8848@mail.mppsystems.com> References: <200702010101.l1111v4H029618@repoman.freebsd.org> <20070202015415.G924@delplex.bde.org> <20070202010632.GA8848@mail.mppsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 01-Feb-2007 at 19:06:32 -0600, Mike Pritchard wrote: > On Fri, Feb 02, 2007 at 03:34:15AM +1100, Bruce Evans wrote: > > On Thu, 1 Feb 2007, Mike Pritchard wrote: > > > > >mpp 2007-02-01 01:01:57 UTC > > > > > > FreeBSD src repository > > > > > > Modified files: > > > sys/ufs/ufs ufs_quota.c > > > Log: > > > Disallow negative UIDs when processing quotactl options. > > > > Er, uids are unsigned, so they cannot be negative. > > There are 1 or 2 utilities out there that will display a > uid/gid of UINT_MAX-2 as -2 :) > > > The function actually takes a u_long id and now uses a bogus cast > > ((int)id) to check for "negative" values. The correct check is > > something like (id <= QUOTA_ID_MAX). ((int)id) would work to restrict > > the id to <= INT_MAX due to previous bogusness (*), but I don't see > > the point of that. If ints are 32-bits then id = INT_MAX gives an > > offset that is about half as huge as id = UINT_MAX (64G?), and if > > ints are 64 bits then id = INT_MAX and id = UINT_MAX both give > > physically impossible offsets. Is the problem with negative ids > > mainly that they are standard for nfs without maproot? > > The basic problem is that the quota file will grow in size > to sizeof(struct dqblk) * highest_id. sizeof(struct dqblk) = 32. > At system startup quotacheck has to read the entire file, > which if the highest_id is extremely large (as a file copied from > an nfs file system without maproot might have, or from some > type of archive file that may have the id = -2) > > The data file was also being incorrectly truncated to a maximum size of > 2^32 bytes due to some incorrect casting when writing out the dqblock data. > > A high id value of 2^24 (16.7 million) allows quotacheck to run > in a "reasonable" (1 min per quota file) amount of time at system startup. > An high id value of 2^25 (33 million) bumps it up to 2 mins per quota file. > > I'd be happy to change the code to use a new QUOTA_ID_MAX value. I'd like something like this. Since PR# 2325 I was using a local hack which mapped everything > 65535 to nobody. A QUOTA_ID_MAX value would make it easy to adjust the boundary. -Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070202111957.GA57142>