Note that you have to be careful to avoid the value of VNOVAL (-1) for a
uid or a gid, or you'll run into trouble with the VFS layer; this is
arguably due to poor design of VFS.  NFSv2 also had problems with reserved
values (as the NFSv2 interface greatly resembles the VFS interface, for
the obvious reasons), but NFSv3 correct most of these.  I'd really like to
get VFS's overloading of vop_setattr() un-overloaded someday, perhaps by
introducing an EXTATTR_NAMESPACE_UFS and having the changes be submitted
via vop_setextattr(), but there's probably some non-atomicity concerns
there that would have to be addressed.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED]      NAI Labs, Safeport Network Services

On Tue, 1 May 2001, Sheldon Hearn wrote:

> On Tue, 01 May 2001 06:56:56 +0900, Yoshihiro Koya wrote:
> 
> > Hello, 
> > chpass: updating the database...
> > pwd_mkdb: 2147483647 > recommended max uid value (65535)
> 
> Gee, that message looks familiar. ;-)
> 
> The warning was a concession that I implemented after discussions with
> BDE.  The way we want to go for now is to have the entire system
> uid_t-clean (currently unsigned 32-bit) but to issue warnings from
> appropriate utilities when values that can't be represented by an
> unsigned short.
> 
> > Added to this, the above pwd_mkdb commands tells me that 
> > the recommended max uid value is 65535, which is 
> > a 16-bit UID, and this value 65535 differs from the restricted value
> > of pw command.
> > It might be better to unify such a recommended UID value on the
> > system.
> 
> Absolutely.  If you have the time, that'd be great!
> 
> Ciao,
> Sheldon.
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to