More on UIDs/Permissions
jeremy at jutley.org
Thu Apr 21 21:12:42 PDT 2005
Bruce Dubbs wrote:
>Jeremy Utley wrote:
>>>In the book, we create a lot of users and groups. Almost none of them
>>>have uids/gids specified. Right now, if a user/group is created without
>>>specifying, a uid value > 1000 or a gid value > 100 is used. The LSB
>>>says system uids/gids should be below 100. I am proposing a book wide
>>>coordinated set of numbers:
>>Actually, my suggestion would be for those system users that are
>>associated with network daemons, to use a group to match the port they
>>open...i.e. apache assigned 80, ssh assigned 22, etc. No real reason,
>>except to try to have SOME rhyme/reason to assignment - those that don't
>>do network stuff can be assigned somewhat arbitrarily.
>Not a bad idea, but we have several ftp and email servers. I thought
>about using the same number for all the ftp servers and the same numbers
>of all the mail servers, but that would make the different packages
They're going to conflict anyway :) Only one FTP server can bind to
port 21, only one mail server can bind to 25, etc. And, in all
technicality, there's no reason why, for example, vsftpd and proftpd
couldn't both use the same username "ftp" :)
>I opted for making the numbers of related apps close
>together. Also it doesn't work for things like pop (110).
>It does work for apache, ssh, and named and I can do that.
>The implementation I was thinking about is to add a page to Chapter 2 or
>Chapter 3 named "About uids and gids" that sumarizes uid/gid issues. It
>should also discuss User Private Groups and mention the interaction and
>possible update of /etc/login.defs.
On a similar note, I'd like to see something that goes into other
method's of device permission handling. Right now, for example, you've
got the audio group handling access to audio permissions and so on.
Kevin Fleming, back when the big discussion about groups happened,
mentioned something about a way of having the user logged into the
console always having access to the devices, but the same user when
logged in remotely wouldn't. That I'd definately be interested in seeing!
More information about the blfs-dev