Re: user/group -- my compromise proposal
SUMMARY:
I've read Ian Murdock's message, and it seems basically fair enough.
It appears to solve the problem of upgrading, at the cost of having
systems potentially end up with a somewhat inconsistent arrangement.
CAVEAT re the DEFAULT:
However, I still feel strongly that the envisaged option should be the
default for adduser.
This is basically because it will make life so much easier for all the
new system administrators we are creating. It may make documentation
easier as well (how do I do XYZ ? Type ..., err, sorry, I mean su to
src and ...).
I believe any political noise will die away when people actually get
to use the system and see that it doesn't cause major problems. In
any case, we must not allow ourselves to be dissuaded from doing
something merely because some very vocal people oppose (or indeed
support) it - issues of substance should carry the day (whichever way
it goes).
Having an arrangement where you have to remember to specify the option
each time you add a user could result in systems where some of the
shared files aren't updateable by some of the appropriate users
because the person to create them had their account created without
the magic option.
Turning it on by default solves this problem.
It also means that when someone comes along and writes a bunch of
programs which allow users to create, modify and delete groups it will
actually be useful to the majority of installations.
Turning it on by mistake for a particular user has less severe
consequences; any problems (which would be aesthetic, really) could be
solved at the sysadmin's leisure rather than having irate users coming
beating on their door saying `joe has left all these files here and I
can't write to them ...' - eg, joe installed GNU Gnomovision in
/usr/local and it created the /usr/local/lib directory but joe's umask
is 022 and etc. etc. etc.
ADDITIONAL COMMENTS ON ADDUSER:
A way to turn private group creation off and on globally would be very
useful, of course - I don't imagine that many systems would want a
half hearted scheme.
That would probably go a long way to keeping both sides happy - even
the side that doesn't get their way on the default.
Incidentally, while we're on the subject of adduser, a place to
configure the default location of home directories would be nice (and
a bit more interaction on the part of adduser before it goes and does
it's stuff).
ADDITIONAL COMMENTS ON UMASK
I'm not convinced about leaving the system umask in /etc/profile (&c)
set to 022 and not setting it in the setup files of users who don't
get their own group (this is of course a slightly different issue to
whether creating an additional group should be the default in
adduser).
This will present us with a problem if you ever want to change the
umask in /etc/profile. I'd suggest that the umask for each user
should be explictly set in their default startup scripts (both the sh
and csh versions). Then you can have what you like in the system file
and it won't matter much, and system upgrades are less likely to have
unexpected consequences.
MISCELLANEOUS COMMENTS:
Starting user UIDs at 1000 is indeed a good idea. Also, Paul Vojta's
comments on the desirable behaviour of adduser under certain
conditions are well considered (labelled C' in his message.)
David Engel is of course correct to say that /boot should be group
`disk' or `root'. Incidentally, what is the permission of / ?
Files in /bin etc. shouldn't really be owned by bin by default, if for
no other reason that it makes NFS easier to use to penetrate the
system. NFS is quite bad enough already without making the holes
*completely* obvious. (Yes, I know this can be fixed by `proper use',
it just strikes me as needless risk.)
Paul Vojta's message ("I'd like to dissect Ian's proposal") was very
interesting. It seems to agree in some sense with what Ian Murdock is
now proposing to do.
I have responded to Remy Card's long messages, which appear to have
been written before Ian Murdock's message, in a separate posting on
each list.
Ian.
SILLY MESSAGE:
Boo!
Reply to: