Linux users and groups
There are numerous tutorials about the basic linux/unix user and group concepts, file permissions and all of that.
I don't intend to rehash that ground here, just add some specific notes for some arcane things.
LDAP issues
We run LDAP on most of our machines, which has great benefits as far as centralizing user and group administration.
Importantly though, this makes the usual files /etc/passwd and /etc/group and others less relevant.
They are still relevant, but are no longer the single place where things are administered. The thing do do instead
of examining these files is to use the commands:
getent passwd
getent group
These emit on standard output the "effective passwd file" and so forth. This work just fine if you are not using LDAP,
so if you were going to write some kind of script to peek at the password file, this would be the sensible thing to
use inside the script.
To change entries, you use commands like useradd, usermod, groups and so forth.
Groups
In a simple world, each user belongs to just one group. But the world is not simple and users typically belong
to many groups as governed by the "group file". The group file has a list of users that belong to each group.
Each user has a primary or default group. When the user creates a file, it will be created as belonging to the
default group for the user creating it. This is true unless the user does something special. A user can use
the newgrp command to change his default group. After that, any files he creates will belong to the group that
the user changed into using newgrp. A user can newgrp without using a password to any group that he is a member
of. If the group has a password, then a user can newgrp to such a group that he does not belong to by using the
password. In other words, the password is only required for users who do not belong to the group.
When a user attempts to access a file, the access is allowed if the user belongs to a group that is allowed to
access the file. (Of course access is allowed by the usual owner and world priveleges as well). There is no
need for a user who belongs to an appropriate group to do any newgrp fiddling just to access an existing file,
that is only relevant for file creation.
A directory may have the group "sticky bit" set. This will cause files created within that directory to belong
to the group that owns the containing directory, not the group of the user creating the file. This is quite handy.
Groups and SVN
Controlling access to an SVN repository goes beyond the usual group and file permission issues, but it does start
there. The basic first level control is to set up a group "svnusers" and add all the users that you want to be
able to access your repository to this group. Repository directories are typically owned by a repository admininstrator
who alone is able to create new repositories (if a multi-repository scheme is used). Directory permissions at the
top level are typically drwxr-s--- and belong the the group svnusers. The repository itself is typically
drwxrwsr-x.
Finer grained access control is possible via a file in the hooks directory, namely
commit-access-control.cfg. This works because standard SVN distributions include a hook script
called pre-commit which calls a perl script commit-access-control.pl. This perl script
is configured by the commit-access-control.cfg. This can all be made to be so at any rate.
As distributed by fedora, only the file pre-commit.tmpl exists and all of this would need to
be borrowed or built. See SVN admin tips from Berkeley
for more information about this scheme.
Have any comments? Questions?
Drop me a line!
Adventures in Computing / tom@mmto.org