On 12/14/2010 21:28, Lennart Poettering wrote: > On Tue, 14.12.10 12:08, Bill Nottingham (notting@xxxxxxxxxx) 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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
