also sprach Michelle Konzack <linux4michelle@freenet.de> [2006.01.26.1643 +0100]:
> Please look into the configuration of 2adduser" in
>
> /etc/adduser.conf
>
> and RTFM: man 5 adduser.conf
Note he didn't ask how to configure it, but why it is as it is.
I answered this question in my book (see my signature):
For new user accounts, \programme{adduser} creates a group with
the same name and uses that group as the user's primary group by
default (see \cref{adduser}). Even though it is certainly
a possibility to make each user a group administrator of the
corresponding group, having an explicit group for each user
account may seem a waste and unnecessary.
However, consider the case of a collaborative environment, in
which different sets of users cooperate on different projects.
A common method to handle such situations is through the use of
shared project spaces in directories belonging to the project's
group, and having their \tterm{setgid} bit set. The latter causes
new files to automatically assume the group of the project's
directory (which is the project's group), assuming it was created
by a proper member of the group.
The missing link now is the \tterm{umask}, which determines the
mode of new files created by a user. To allow new files to be
usable by the other members of the project group, the group
permissions presumably need to be read-write on all shared files.
This can be achieved by setting the \tterm{umask} of all users
involved to 0007 (for instance, in \file{/etc/profile}, or the
user-specific initialisation scripts).
A problem arises when, as in the classical Unix case, all users
belong to \eg\ the \group{users} group by default. Since the
\tterm{umask} is set for the entire shell session (and if set in
the initialisation script, then for every shell session), when
Alice subsequently writes a private letter to a friend, all other
members of \group{users} can read \emph{and even edit} the leter,
since it will be created with read-write permissions for the
group, and the group will be \tterm{users} by default. To guard
against this situation, every user gets an explicit group by
default.
Note that the advent of libpam-umask hopefully makes this a lot
easier in the future!
--
Please do not send copies of list mail to me; I read the list!
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer and author: http://debiansystem.info
`. `'`
`- Debian - when you have better things to do than fixing a system
Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver!
perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
Attachment:
signature.asc
Description: Digital signature (GPG/PGP)