Chris's Wiki :: blog/linux/FHSNotAlwaysRightII

More on Linux FHS and `/var`

January 16, 2011

Through my Referer logs, I stumbled over this reply to my earlier entry on the FHS, which points out /srv as the answer to my criticisms. However, as the author of it notes:

[...] Then again I haven't seen any package management that does something to /srv [...]

Well, yeah. That's the problem; no one uses it. The FHS in theory might include /srv to deal with my exact criticisms, but it doesn't in practice because no one uses it. This is more than a matter of semantics and a little bit of configuration annoyance; as a commentator on my SELinux entry noted sort of indirectly, people have built software that assumes you are following the in-real-life FHS and thus are putting your data in the duly designated places in /var.

This points out my ultimate problem with the FHS and people assuming that it is always right: these people build software that requires you to follow the FHS without pausing to find out if people actually follow the FHS in real life and if the decisions that the FHS mandates actually make sense. When I don't follow the FHS for various good reasons, this software blows up in my face and makes me grumpy until I turn it off.

(I'm sure that there's people following the FHS and putting real data in /var; it's the path of least resistance, machines these days have huge disks anyways, and if you don't have that much data and you don't have significant infrastructure, you don't really care about these issues. I'll admit that we have some machines set up that way for exactly that reason.)

Update: I've been both unclear and somewhat too extreme here. See the comments for details.

Comments on this page:

From 77.249.14.105 at 2011-01-17 02:05:29:

that's not true, we use /srv for all our nfs shares that get mounted by esx, for instance. And also for quite a big sybase database. So there is at least one company using /srv.

On your selinux rants: just learn how to use it. It's trivial if you rtfm. The centos wiki has quite a nice guide to it.

-- natxo

From 83.150.82.85 at 2011-01-17 04:04:08:

Isn't /srv supposed to be untouched by the package systems like /opt according to FHS? That said, packages should be built so that the user can configure them to use /srv if it pleases the user.

From 194.74.151.201 at 2011-01-17 05:16:00:

That's the problem; no one uses it.

Seriously? Based on what information?

Software doesn't ship with it's configuration files pointing at /srv because package management explicitly states that packages shouldn't touch it. That serves as no indication as to how you should use /srv though. A cursory grep through /etc/selinux/targeted/contexts/files on EL5 shows a number of default contexts for places that you can relocate data under /srv.
/srv/.* system_u:object_r:var_t:s0
/srv/([^/]*/)?ftp(/.*)? system_u:object_r:public_content_t:s0
/srv/([^/]*/)?web(/.*)? system_u:object_r:httpd_sys_content_t:s0
/srv/([^/]*/)?www(/.*)? system_u:object_r:httpd_sys_content_t:s0
/srv/([^/]*/)?rsync(/.*)?       system_u:object_r:public_content_t:s0
- Dan Carley

By cks at 2011-01-17 09:04:51:

To clarify: by 'no one uses it', I meant no distribution uses it and configures programs to use it and so on. Individual sysadmins can use /srv just as much as we can use anything else, but that doesn't help with things like SELinux.

(Even if distributions can't put files in /srv, they could mention it in configuration examples. I've never seen any mentions of it in sample and default config files, even as comments saying 'if you have a lot of stuff, uncomment this stanza to put it in the FHS location for that, /srv'.)

As for /srv being mentioned in SELinux configurations: on the machines I have with SELinux packages, the coverage is incomplete. For example, neither PostgreSQL nor MySQL have their SELinux stuff set up to work with /srv.

From 80.254.147.20 at 2011-01-17 10:42:07:

"I meant no distribution uses it and configures programs to use it and so on."

Easy tiger - that's quite a sweeping statement that I'm guessing is not backed up with research you can show.

SUSE Linux Enterprise Server (SLES) uses "/srv" by default for at least Apache virtual hosts and the default location for an FTP server.

There's probably more, but ther're the two configured by defauklt on my rather minimal install.

By cks at 2011-01-17 12:18:07:

You're right; my research is based on Ubuntu (with an assumption that it applied to Debian as well) and Fedora/RHEL (I don't count them as separate distributions for this sort of stuff). I didn't look at others, and I should have.

Now that I start looking, I wonder just how widely supported SELinux is at all. SLES 11 doesn't support it, Ubuntu may support it but doesn't make it the default (it doesn't even install the tools by default), Debian seems similar to Ubuntu, Gentoo has vague gestures at support, and after that I lost interest. It's probably the case that my core issue is just a Fedora/RHEL grump.

From 80.254.147.20 at 2011-01-18 03:51:04:

my core issue is just a Fedora/RHEL grump

Linux distributions are very much a tempestuous love/hate relationship :)

By default SLES and Ubuntu (not sure about Debian) use AppArmor as their mandatory access control (MAC) with SELinux available. I’m unaware of AppArmor availability for RHEL/CentOS, but thanks to a quick update from Wikipedia I’m now informed “AppArmor was integrated into the October 2010, 2.6.36 kernel release” so it’s use could become more widespread.

AppArmor/SELinux are also on my ever growing list of technologies I really should be familiar with (that list grows far too quickly). From what commentary I’ve read AppArmor is less complex and is a little easier to work with due to its learning mode which can produce a profile and that it works on paths rather than SELinux use of "security labels" on files/inodes (SELinux proponents would counter argue that AppArmors access control is less comprehensive).

As with most things I suppose it’s a matter of understanding the differences, the implications of those differences and choosing what is most aligned with your needs. Of course gaining that understanding requires evermore of that scare resource – time.

Just to save some typing:
http://en.wikipedia.org/wiki/Mandatory_access_control
http://en.wikipedia.org/wiki/Security-Enhanced_Linux
http://en.wikipedia.org/wiki/AppArmor
http://en.wikipedia.org/wiki/Comparison_of_Linux_distributions#Security_features

Great blog Chris, thanks for the informative commentary.

S

Written on 16 January 2011.

«	Why I don't use either a thin client or a fat client

Wrestling with how to design a schema for a Django app

More on Linux FHS and /var

Comments on this page:

More on Linux FHS and `/var`