[systemd-devel] [PATCH 2/4] mount-setup: introduce mount_setup_run_dirs()
Michal Sekletar
msekleta at redhat.com
Tue Oct 7 05:14:06 PDT 2014
On Thu, Oct 02, 2014 at 11:43:22AM +0200, Lennart Poettering wrote:
> On Thu, 02.10.14 09:57, Michal Sekletar (msekleta at redhat.com) wrote:
>
> > In cases when we are running as system manager, but we don't have the
> > capability to mount filesystems don't call mount_setup(). However we
> > assume that some directories (e.g. /run/systemd) are always
> > around. Hence don't create those directories in mount_setup().
> > ---
> > src/core/main.c | 7 ++++++-
> > src/core/mount-setup.c | 20 ++++++++++++--------
> > src/core/mount-setup.h | 1 +
> > 3 files changed, 19 insertions(+), 9 deletions(-)
> >
> > diff --git a/src/core/main.c b/src/core/main.c
> > index 1a62e04..fcd9471 100644
> > --- a/src/core/main.c
> > +++ b/src/core/main.c
> > @@ -1393,10 +1393,15 @@ int main(int argc, char *argv[]) {
> >
> > /* Mount /proc, /sys and friends, so that /proc/cmdline and
> > * /proc/$PID/fd is available. */
> > - if (getpid() == 1) {
> > + if (getpid() == 1 && have_effective_cap(CAP_SYS_ADMIN)) {
> > r = mount_setup(loaded_policy);
> > if (r < 0)
> > goto finish;
>
> Hmm, is this really necessary? I mean, the code in mount_setup() will
> anyway only mount what is missing, but not overmount what is already
> mounted.
I think it is necessary to make possible to run systemd in a docker container.
> Hence, if a container manager mounts everything properly, then mount_setup()
> should be a NOP anyway...
In theory yes, but in fact not having /run mounted as tmpfs is default in the docker
container. I have no strong opinion on whether this is sensible or not, however
I think that systemd can be made more resilient and handle such cases.
Now systemd will try to mount /run on tmpfs, such attempt will fail because of
missing capability and then systemd will just hang.
Michal
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
More information about the systemd-devel
mailing list