`staff` and `adm` Group on Debian Boxes
We had quite a few discussions on our internal usage of the filesystem. Usually we try to keep to the Linux FHS. That is we use /srv for application data, /opt for local installations of 3rd party software. But so far we couldn’t get an agreement on how to deal with /usr/local.
One thing that bugged us was: “What the hell is the
</strong><em><strong>staff</strong></em><strong> group about anyway”. Well I started investigating a bit.
- what is actually writeable according to the Debian Policy
- what is actually writeable (now really)
According to the Debian Policy there are 2 groups prepared for a site to use, those are:
- staff and
The Securing Debian HOWTO mentions it’s uses in the FAQ part in chapter 12:
However that wasn’t good enough for me, so I fired up a new debian instance and had a look at which files (or directories for that matter) are actually writable by the staff group:
Long story short: It seems only 2 directories are writeable:
of course that includes all the subdirectories in a default Debian installation. While we’re at it we can also check the same for the
Interestingly enough, nothing came back. So let’s check what we can read with this group and also what the
staff group can read:
<em>adm</em> group returned a few hits in the
<em>/var/log</em> directory while the
<em>staff</em> group had read access to everything under
<em>/usr/local</em>. From my point of view it seems that
<em>adm</em> are perfectly useable for administrators as long as there aren’t any critical packages installed by “exploiting” these memberships. I rather see such things installed by creating a proper package and using apt-get.
Of course there should be some testing done on a regular basis that no files or directories are in a place where
<em>adm</em> people shouldn’t write to.
Now I just need to completely convince my colleagues to use an existing infrastructure instead of further maintaining our home grown solution.Server!/Horror