On 02-Sep-99 Sheldon Hearn wrote: > > > On Thu, 02 Sep 1999 15:42:56 +0200, Markus Stumpf wrote: > >> The numeric id IS important. >> How do you think NFS maintains privileges across machines? > > I have no idea how NFS works. :-)
Time to learn. The uid/guid is only stored as a number, and this number is sent across NFS, that's all, no name. So, suppose I have the stmp:25 user on my BSD box. Now, I export my mail spool to other computers so that users can read their mail everywhere. Suppose user 25 on some other Unix flavor boxes is the www user. Then, the www user will have access to the mail spool, but not that other Unix's mail owner. Thus, for admin purposes, and admininistrative users that "own" a service have to be setup by the admins to make sure the uid/gid is the same everywhere. The admin can't count on the built-in uid/gid's since they vary from Unix to Unix. > I _do_ know that, if machines across the network need to know about > magical IDs on their peers, then it's nothing like how SMTP works, > and > thus irrelevant to the username I think we should add. It's not SMTP that is a problem, its NFS and the actual sharing of the drive space. >> This also has nothing to do with emotions ... it's my experience >> from >> the time I worked at the computing staff at the univ, where we had >> to >> maintain a few thousand users on a few hundred machines of all >> types. > > The tools which help you add users default to a minimum UID of 1000. > If > users have been added with very low UID's, they've been added > manually. > This change won't be uncomfortable for people who have their hands > that > deep into the system. That's how it works on FreeBSD, it doesn't necessarily work that on other Unices. The problem has to do with the interaction of FreeBSD with other Unices. > More to the point, though, who cares whether the user's ID is 25 on > one > box, 12 on another and 2525 on a third? The _name_ is what we're > looking > for, here. NFS does. That's his point. ;) >> In some perspectives ($HOMEs, mail, standard programs, shared >> document >> space) the machines had to look and feel alike for the users. >> >> We noticed that the predefined uids/gids on the systems were nearly >> useless for that tasks (as they were all different) > > ID's _are_ useless for the task of look'n'feel. That's what usernames > are for. Yes, usernames are for look and feel, but usernames are keyed on user ID's, so if the user ID's don't match, the usernames will change from machine to machine. Suppose on machine foo user a has id 400 and user b has id 401. Now, suppose on machine bar user a has id 401 and user b has id 400. Then, on machine bar, user a can't read his mail or home directory (assumiing they are exported from machine foo to machine bar), but he can read user b's mail and write to user b's home directory. This is why uid/gid's have to be consistent for shared filesystems and users. >> If in such an environemt the uid 25 is already used for some other >> service it's a pain to integrate new FreeBSD machines from the >> moment FreeBSD comes shipped with uid 25 allocated to a user smtp. > > I'm not catering for people who create accounts with low UID's and > then > try to > > 1) Merge in master.passwd entries from subsequent FreeBSD > releases without using their eyes. > > 2) Install STABLE packages on RELEASE systems. > > Ciao, > Sheldon. The problem is that you cannot assume a FreeBSD-only environment. Also, since sendmail wouldn't use the smtp user and the ports for the other mailers already create the necessary user(s) (and since qmail requires 7 users), smtp would go unused, unless the postfix/exim ports were modified to use smtp instead of their own users. So, we then have a mandatory, pre-installed user that is not used in the base system but only by 2 external packages that already have the facilities to create the users you need. --- John Baldwin <jobal...@vt.edu> -- http://www.cslab.vt.edu/~jbaldwin/ PGP Key: http://www.cslab.vt.edu/~jbaldwin/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
