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 <[EMAIL PROTECTED]> -- 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
