Server!/Horror! I have a magnet and I don't mind using it!

`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.

According to the Debian Policy there are 2 groups prepared for a site to use, those are:

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:

sudo find / -xdev -group staff -perm +0020 -exec ls -ld {} \;

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 adm group:

sudo find / -xdev -group adm -perm +0020 -exec ls -ld {} \;

Interestingly enough, nothing came back. So let’s check what we can read with this group and also what the staff group can read:

sudo find / -xdev -group adm -perm +0010 -exec ls -ld {} \;
sudo find / -xdev -group staff -perm +0010 -exec ls -ld {} \;

The <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>/var/local</em> and <em>/usr/local</em>. From my point of view it seems that <em>staff</em> and <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>staff</em> or <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.

Generated: 2017-11-02 10:20:47 +0100