On 12/14/2010 21:28, Lennart Poettering wrote:
On Tue, 14.12.10 12:08, Bill Nottingham (notting(a)redhat.com) wrote:
Thanks, Bill, for replying in so much detail.
Here are a few other points:
> - systemd mounts API filesystems without them needing to be in
> /etc/fstab. This is for a variety of reasons - having every system
> installer have to write /proc, /sys, and so on is pretty wasteful. It
> also can give inexperienced admins the idea that it's configuration
> that can be changed - they then rename the mount point from /proc
> to /processes and *kaboom*.
The main reason we mount /sys and /proc and friends in C code this early
is that we simply need them ourselves. To do what systemd does, it must
be able to rely that it can read process data from /proc, or device
information from /sys, or cgroup information from /sys/fs/cgroup.
There is simply no way around this, and just to make a point, Upstart
mounts some of those FS too, in C code (however not /dev/shm), there's
very little effective difference here, and if people whine and say
"things have never een done this way, you a are breaking UNIX", then I
can only reply, that that's simply wrong.
Having said all this I actually believe that there is very little point
in listing "API" file systems like these in /etc/fstab. They are after
all API, hence only relevant for application code, not really useful for
direct interaction or even reconfiguation by the user. Or in other
words: While it definitely makes sense to ount /dev/sda5 to whatever
mount point the user chooses, the mount point and options for the API
file systems are pretty much an implementation detail for the OS, and
there should never be a need to change them.
In order to make things secure we minimize what is allowd on the various
API file systems we mount. That includes that we set noexec and similar
options for the file systems involved. The interface how to access
/dev/shm is called shm_open(), and given that this is how it is there is
very little reason to allow people to execute binaries from them. Of
course, this is a very recent change, and at this point while we assume
that this will not break any valid use of this directory, we cannot be
sure about this, so we'd be very interested to learn why exactly you
want the noexec to be dropped. What is your application that needs that?
If there is a point in dropping the noexec, we'll definitely be willing
to do so, but if the only reason would be "I always misused /dev/shm as
a scratch space", then we won't be very convinced. The API fom /dev/shm
is shm_open(), and if you place other stuff in there, then you are
misusing it and actually creating all kinds of namespacing problems
(since /dev/shm is actually an all-user shared namespace), and we aren't
particularly keen to support such misuses by default.
That said, because we anticipated that there are some valid uses to
change the settings of these mount points (e.g. change size= for tmpfs)
we actually do apply the options from /etc/fstab, if the file system is
listed there. So if you really really want to misuse /dev/shm, you
may. Apparently this particular feature was broken (see Bill's comments),
and hence please file a bug about this.
I'm fine with that as long as it is documented, particularly in the
fstab man page and as commentary in /etc/fstab on newly-installed
systems so people who read it and notice missing filesystems don't
panic. Thanks for explaining your thought process.
It sounds like /tmp would be a better location to remove noexec from
than /dev/shm if one needs memory-backed storage for things and doesn't
want to create a new filesystem for that purpose.