On Sat, Oct 13, 2001 at 02:30:50AM -0700, Crist J. Clark wrote: > On Sat, Oct 13, 2001 at 01:05:10PM +0400, Yar Tikhiy wrote: > > On Fri, Oct 12, 2001 at 07:24:57PM +0300, Peter Pentchev wrote: > > > On Fri, Oct 12, 2001 at 09:52:10AM -0600, Warner Losh wrote: > > > > In message <[EMAIL PROTECTED]> Yar Tikhiy writes: > > > > : Is there any reason to omit the period ('.') from the list of valid > > > > : characters? With the period included, the list would conform to > > > > : POSIX's definition of a valid user name. > > > > > > > > Not any more. it used to be that chown user.group would be > > > > ambiguous. now it isn't, since user:group is the right syntax. > > > > > > This might be a problem for NIS or Kerberos domains - an older version > > > of FreeBSD might be confuzzled by usernames which are perfectly valid > > > for the rest of the client boxes. > > > > Oh, I see. Given that the only issue about the period in user names > > is compatibility, should pw(8) and adduser(8) still reject it or accept > > it and print a warning? I think printing a warning is better since > > the validity check is by no means a panacea--a stupid admin can always > > use vipw(8) to create any kind of an invalid user name. > > That arguement goes both ways. They can use vipw(8) or they can edit > master.passwd directly if they insist on living dangerously. They can > even hack pw(8) or adduser(8) if they want. But no reason to let > pw(8) or adduser(8) fsck up their systems for them. After all, tools > like adduser(8) are aimed more towards the inexperienced admin. If any > administrative apps are going to do hand-holding, adduser(8) is one of > them.
Good point! However, there's a certain "lobby" of people who need weird chars in user names (e.g. bin/22860 and the followup to it about I18N) and who prefer the automated tools to vipw/mkdir/cp/chown. So what about keeping the strict validity check by default and adding an option to adduser(8) and pw(8) that would turn off the check? BTW, coming to a final conclusion on this issue would help to close a number of problem reports, no matter what the conclusion will be. -- Yar To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
