Discussion:
SystemD, Gnome permission problems
(too old to reply)
dean
2015-04-10 22:57:01 UTC
Permalink
Hi guys,

Firstly i apologize if I'm in the wrong place, tell me where to go if i
am ;-).

I am having some permission problems, following is some syslog entries:

gnome-session[2739]: (gnome-settings-daemon:2809):
housekeeping-plugin-WARNING **: Failed to enumerate children of
/tmp/systemd-private-4edf24dfb47a4c97917dcbd0468d3a56-colord.service-PxIGXf:
Permission denied

gnome-session[2739]:(gnome-settings-daemon:2809):
housekeeping-plugin-WARNING **: Failed to enumerate children
of /tmp/pulse-PKdhtXMmr18n: Permission denied

gnome-session[2739]:(gnome-settings-daemon:2809):
housekeeping-plugin-WARNING **: Failed to enumerate children of
/var/tmp/systemd-private-4edf24dfb47a4c97917dcbd0468d3a56-systemd-timesyncd.service-HZKK6o:
Permission denied

gnome-session[2739]: (gnome-settings-daemon:2809):
housekeeping-plugin-WARNING **: Failed to enumerate children of
/var/tmp/systemd-private-4edf24dfb47a4c97917dcbd0468d3a56-colord.service-pIv5Bg:
Permission denied

I have changed permissions on the folders in /tmp but their either
reverting or being recreated. Is this a Gnome or systemD problem?
Its been this way for some time. What permissions are these
files/folders supposed to be?

Any help would be appreciated.

Regards,
Dean
dean
2015-04-10 23:13:33 UTC
Permalink
Post by dean
Hi guys,
Firstly i apologize if I'm in the wrong place, tell me where to go if i
am ;-).
housekeeping-plugin-WARNING **: Failed to enumerate children of
Permission denied
housekeeping-plugin-WARNING **: Failed to enumerate children
of /tmp/pulse-PKdhtXMmr18n: Permission denied
housekeeping-plugin-WARNING **: Failed to enumerate children of
Permission denied
housekeeping-plugin-WARNING **: Failed to enumerate children of
Permission denied
I have changed permissions on the folders in /tmp but their either
reverting or being recreated. Is this a Gnome or systemD problem?
Its been this way for some time. What permissions are these
files/folders supposed to be?
Any help would be appreciated.
It's not much of a problem. Since /tmp is shared, software owned by
various users often has private subdirectories under it (which other
uids cannot access), and gnome-settings-daemon is just being
unnecessarily verbose about that.
--
Ok thanks for your prompt reply. It is my understanding the the
house-keeping-plugin "cleans" /tmp so does it need access? Does systemD
"clean" its own /tmp files/folders?
Kai Krakow
2015-04-11 12:26:57 UTC
Permalink
Post by dean
Ok thanks for your prompt reply. It is my understanding the the
house-keeping-plugin "cleans" /tmp so does it need access? Does systemD
"clean" its own /tmp files/folders?
Yes, it does. See "man tmpfiles.d", it ships with defaults for the tmp
directory.

The directories you are seeing are private (isolated) bind mounts for
several services which systemd does the house keeping for. It comes from the
service option PrivateTmp in *.service files. It provides a service its own
private and empty tmp directory for security reasons.
--
Replies to list only preferred.
Zbigniew Jędrzejewski-Szmek
2015-04-11 16:21:46 UTC
Permalink
Post by dean
Ok thanks for your prompt reply. It is my understanding the the
house-keeping-plugin "cleans" /tmp so does it need access?
That sounds wrong. First, systemd is already cleaning /tmp, so nothing
good is going to come out of cleaning it twice. Second, doing cleanup
as unprivileged user does not really work. If the user is not running,
the cleanup is not going to happen, so on a multi-user system, when the
user logs out, files would stay around infinetely. So cleanup from
the graphical session is ineffective. More importantly, an unprivileged
user cannot access files without bumping their access time stamp. So
trying to do the cleanup as an unprivileged user actually interferes
with systemd-tmpfiles (see df99a9ef5bb7a89b92 and
https://bugzilla.redhat.com/show_bug.cgi?id=1183684).

Zbyszek
Mantas Mikulėnas
2015-04-11 17:21:13 UTC
Permalink
On Sat, Apr 11, 2015 at 7:21 PM, Zbigniew Jędrzejewski-Szmek <
Post by Zbigniew Jędrzejewski-Szmek
Post by dean
Ok thanks for your prompt reply. It is my understanding the the
house-keeping-plugin "cleans" /tmp so does it need access?
That sounds wrong. First, systemd is already cleaning /tmp, so nothing
good is going to come out of cleaning it twice.
I think the difference here is that g-s-d has per-user configuration, so
user A can set the expiry for their own files to 1 day, user B can set it
to 7 days, and systemd can enforce a system-wide maximum of 10 days.

Though it can be confusing if the GNOME UI allows selecting a longer expiry
than systemd has.
Post by Zbigniew Jędrzejewski-Szmek
If the user is not running,
the cleanup is not going to happen, so on a multi-user system, when the
user logs out, files would stay around infinetely.
Well, tmpfiles.d enforces it anyway.
Post by Zbigniew Jędrzejewski-Szmek
So cleanup from
the graphical session is ineffective. More importantly, an unprivileged
user cannot access files without bumping their access time stamp. So
trying to do the cleanup as an unprivileged user actually interferes
with systemd-tmpfiles (see df99a9ef5bb7a89b92 and
https://bugzilla.redhat.com/show_bug.cgi?id=1183684).
Even a stat()? Ouch.
--
Mantas Mikulėnas <***@gmail.com>
Elias Probst
2015-04-12 15:59:02 UTC
Permalink
I'm wondering if we should provide better per-user tmpfiles support.
For example, if we allowed a set of "user" tmpfiles, which would
be executed by the system instance, but would be considered relative to
the home directory and XDG_RUNTIME_DIR (~ or %h to refer to the home
directory, %t to XDG_RUNTIME_DIR, ...). We would execute that for every
user.
Which makes me wonder again, why tmpfiles.d was never implemented in the
way all other units are implemented.
Currently, it's impossible to declare a dependency of a service upon a
tmpdir, which feels out of line with the way things are usually handled
in a systemd-based system.
OpenVPN requires /run/openvpn/ to exist before being able to start.
This leads to the following possible scenarios to make OpenVPN usable on
a system where OpenVPN was just installed (and there was no reboot to
A#
- the package manager creates /run/openvpn as part of of its postinst
routine. This is duplicated effort and could easily go out of sync with
the definition in OpenVPN's tmpfiles.d configuration
B#
- the package manager calls "systemd-tmpfiles --create 
" whenever a
tmpfiles.d configuration was installed. This might still be the most
straightforward way, but it could still happen that a user manually
deletes the directory and than at a later point attempts to start a
service depending on it
C#
- the user has to create /run/openvpn manually (I don't think I have to
outline why this is no "correct" solution)
D#
- creation of tmpfile directories is left to the application (again
duplicated effort and the wrong place to do it, when there is a
centralized mechanism for handling this properly)
E#
- the service unit contains something like "ExecPre=/bin/mkdir 
". Again
duplicated effort and the wrong place to do it.
F#
- the service file contains a RuntimeDirectory directive.
;-)
Ha! Perfect! Thanks a lot for pointing this out.

My initial bugreport against Gentoo [1] regarding this issue is older
than the implementation of RuntimeDirectory [2] - time for updating the
bugreport + getting upstream (OpenVPN) involved to ship an updated
service unit and get rid of their tmpfiles.d conf.

[1] https://bugs.gentoo.org/show_bug.cgi?id=462118
[2] http://cgit.freedesktop.org/systemd/systemd/commit/?id=e66cf1a3

- Elias
Kai Krakow
2015-04-12 17:51:41 UTC
Permalink
Post by Elias Probst
I'm wondering if we should provide better per-user tmpfiles support.
For example, if we allowed a set of "user" tmpfiles, which would
be executed by the system instance, but would be considered relative to
the home directory and XDG_RUNTIME_DIR (~ or %h to refer to the home
directory, %t to XDG_RUNTIME_DIR, ...). We would execute that for every
user.
Which makes me wonder again, why tmpfiles.d was never implemented in the
way all other units are implemented.
Currently, it's impossible to declare a dependency of a service upon a
tmpdir, which feels out of line with the way things are usually handled
in a systemd-based system.
OpenVPN requires /run/openvpn/ to exist before being able to start.
This leads to the following possible scenarios to make OpenVPN usable on
a system where OpenVPN was just installed (and there was no reboot to
A#
- the package manager creates /run/openvpn as part of of its postinst
routine. This is duplicated effort and could easily go out of sync with
the definition in OpenVPN's tmpfiles.d configuration
B#
- the package manager calls "systemd-tmpfiles --create …" whenever a
tmpfiles.d configuration was installed. This might still be the most
straightforward way, but it could still happen that a user manually
deletes the directory and than at a later point attempts to start a
service depending on it
C#
- the user has to create /run/openvpn manually (I don't think I have to
outline why this is no "correct" solution)
D#
- creation of tmpfile directories is left to the application (again
duplicated effort and the wrong place to do it, when there is a
centralized mechanism for handling this properly)
E#
- the service unit contains something like "ExecPre=/bin/mkdir …". Again
duplicated effort and the wrong place to do it.
F#
- the service file contains a RuntimeDirectory directive.
;-)
Ha! Perfect! Thanks a lot for pointing this out.
You're welcome...
Post by Elias Probst
My initial bugreport against Gentoo [1] regarding this issue is older
than the implementation of RuntimeDirectory [2] - time for updating the
bugreport + getting upstream (OpenVPN) involved to ship an updated
service unit and get rid of their tmpfiles.d conf.
[1] https://bugs.gentoo.org/show_bug.cgi?id=462118
[2] http://cgit.freedesktop.org/systemd/systemd/commit/?id=e66cf1a3
A lot of packages should use this directive in Gentoo if I looked at
/usr/lib/tmpfiles.d... There seem to be a lot of Gentoo-generated files
(those without any comments) which could by migrated into the service file
instead.

But, as Lennart pointed out, it would really be better if daemons created
those directories by themselves. I'd not put that under the term "duplicated
effort" - indeed you are having duplicated effort currently because every
init system has to take care of creating those directories, sometimes even
depending on configuration files, e.g. mysql configures this in the
configuration file but also in the init file. As a sysadmin I have to take
care to change all possible places. If, in this example, mysql would simply
create this directory on its own, all would be good - no more duplicated
effort. Well, OTOH mysql isn't started as root, thus it cannot create this
directory. So, such services are dependent on duplicated work - but at least
RuntimeDirectory is the right place to do it then.

I'd really prefer systemd's idea of services should create their runtime
environment themselves on first start as complete as possible. Letting the
package manager create all those empty runtime directories with .keep files
so they become part of backups and do not become cleaned up, is really
cumbersome and incomplete, and duplicate work because you have configuration
in two places: the config file and the package manager. If I wanted to move
runtime directories I'd have to configure the new directories but also
create them or move them. Upon update, the package manager will recreate
empty bogus directories. This should really go away.
--
Replies to list only preferred.
Lennart Poettering
2015-04-12 17:19:07 UTC
Permalink
I'm wondering if we should provide better per-user tmpfiles support.
For example, if we allowed a set of "user" tmpfiles, which would
be executed by the system instance, but would be considered relative to
the home directory and XDG_RUNTIME_DIR (~ or %h to refer to the home directory,
%t to XDG_RUNTIME_DIR, ...). We would execute that for every user.
I'd be careful with this. I mean, I generally think that the fact that
we need tmpfiles is not a strength, but really just a work-around
for limitations of Linux. The tool covers four major usecases:

1. set up the work environment for daemons which are too dumb to do
this on their own

2. set up the work environment for daemins that never run privileged,
and hence cannot set up their work environment

3. Reserve a few file/directory names, to avoid namespace clashes in
world-writable directories. Most notably that's the X11 stuff in
/tmp.

4. Do "aging/clean-up" of /tmp.

Now, of these the first item is a work-around for broken daemons, and
this should really be better fixed in the daemons themselves. A daemon
that does not require tmpfiles is a good daemon. The third item is a
work-around against really broken semantics of X11, that cannot really
be fixed without breaking compat... But this issue is certainly not
something new code will fall for (hopefully)... The fourth item is a
work-around for broken semantics of UNIX, where files cannot be bound
to proper lifecycles of other objects, such as processes... "Aging"
these dirs is actually really nasty, since its cleanups are in no way
bound to the actual algorithms creating the files: code that generates
a lot of files in a short time, will be cleaned up only much later,
when the tmpfiles job happens to runs again...

Only the second item is really a genuinely useful thing I believe, all
the others are work-arounds around otherwise crappy designed
code... And for the second item things like RuntimeDirectory= are
probably a much better option, since it has properly synced up
lifecycle guarantees...

Now, if we look at all of this and how it would apply to the
unprivileged user session, then I don't think issue #1 applies, simply
because desktop software traditionally always was capable of setting
up its own work environment, simply because boot scripts and RPM
scripts couldn't cover new, unseen logins. Issue #2 doesn't apply
because everything is unprivileged. Issue #3 doesn't apply, either,
since this is about protecting system code against unprivileged code,
but not unpriviliged code against itself. Finally, the solution for #4
that we apply on the system already covers this for the session too.

The fact that tmpfiles exists is sad, and we shouldn't add this to the
session, so that the same sad practices we see on system daemons are
also adopted by desktop software...

Moreover, I'd always be careful with adding privileged code that
operates on unprivileged files, based on unprivileged configuration. I
mean, the cleaning of /tmp has always been a source of security
issues, it's really hard not to do things wrong when operating as
privileged code on unprivileged files (think symlink attacks!), but
it's a whole new dimension of risk, if we not only operate on those
unprivileged files, but also use unprivileged user-supplied configuration...

Hence, if this is done at all, it really should be the user's code
that runs this, not the system code.
gnome could possibly replace its custom thumbnails cleaner with a few
lines of tmpfiles config. There would be two advantages: creation time
cleanup could be replaced with access time cleanup, cleanup wouldn't
be dependent on the session running.
I think it would be a good idea if the thumbnailing code of GNOME
would clean up the thumbnails stuff properly on its own, and that from
the same code that writes the thumbnails, in a similar way as journald
keeps track of its journal directory. That's the only way to make this
robust: don't clean it up triggered on time, but closely bound to the
algorithm that might fill it up.

I hope this makes sense?

Lennart
--
Lennart Poettering, Red Hat
Zbigniew Jędrzejewski-Szmek
2015-04-13 02:37:28 UTC
Permalink
Post by Lennart Poettering
I'm wondering if we should provide better per-user tmpfiles support.
For example, if we allowed a set of "user" tmpfiles, which would
be executed by the system instance, but would be considered relative to
the home directory and XDG_RUNTIME_DIR (~ or %h to refer to the home directory,
%t to XDG_RUNTIME_DIR, ...). We would execute that for every user.
I'd be careful with this. I mean, I generally think that the fact that
we need tmpfiles is not a strength, but really just a work-around
1. set up the work environment for daemons which are too dumb to do
this on their own
2. set up the work environment for daemins that never run privileged,
and hence cannot set up their work environment
3. Reserve a few file/directory names, to avoid namespace clashes in
world-writable directories. Most notably that's the X11 stuff in
/tmp.
4. Do "aging/clean-up" of /tmp.
Now, of these the first item is a work-around for broken daemons, and
this should really be better fixed in the daemons themselves. A daemon
that does not require tmpfiles is a good daemon. The third item is a
work-around against really broken semantics of X11, that cannot really
be fixed without breaking compat... But this issue is certainly not
something new code will fall for (hopefully)... The fourth item is a
work-around for broken semantics of UNIX, where files cannot be bound
to proper lifecycles of other objects, such as processes... "Aging"
these dirs is actually really nasty, since its cleanups are in no way
bound to the actual algorithms creating the files: code that generates
a lot of files in a short time, will be cleaned up only much later,
when the tmpfiles job happens to runs again...
But /tmp is also used for shared state (between services, but also
between different applications run by the same user, different
sessions of the same user, etc.). Such files are not bound to any
process, or any session, and should not be. For example, when I download
stuff I often stick it in /tmp, so that it stays around if I need it, but
goes away without me taking any concious action after some time.
Gnome's thumbnails are a bit like this: they are not bound to the life
cycle of anything, we just want them to go away when they have not been
used for a while.

The application which creates thumbnails (or other similar caches)
*should* take care to not use to much space when creating things rapidly.
I assume that gnome does that already. But the application cannot really
implement good time based cleanup, especially that time based cleanup
is especially useful when the application is *not* running.

I'm aware of various short-comings of shared spaces and time-based
cleanup, but I don't think there's a better alternative for many cases.
Or more precisely: it works best for cooperative sharing, where various
entities involved are not malign, but not omniscient either.

[snip]
Post by Lennart Poettering
The fact that tmpfiles exists is sad, and we shouldn't add this to the
session, so that the same sad practices we see on system daemons are
also adopted by desktop software...
Agreed, for 1-3, but not yet for 4.
Post by Lennart Poettering
Moreover, I'd always be careful with adding privileged code that
operates on unprivileged files, based on unprivileged configuration. I
mean, the cleaning of /tmp has always been a source of security
issues, it's really hard not to do things wrong when operating as
privileged code on unprivileged files (think symlink attacks!), but
it's a whole new dimension of risk, if we not only operate on those
unprivileged files, but also use unprivileged user-supplied configuration...
Hence, if this is done at all, it really should be the user's code
that runs this, not the system code.
Well, the whole discussion started with the fact that this cannot be
implemented as user code without being crippled.
Post by Lennart Poettering
gnome could possibly replace its custom thumbnails cleaner with a few
lines of tmpfiles config. There would be two advantages: creation time
cleanup could be replaced with access time cleanup, cleanup wouldn't
be dependent on the session running.
I think it would be a good idea if the thumbnailing code of GNOME
would clean up the thumbnails stuff properly on its own, and that from
the same code that writes the thumbnails, in a similar way as journald
keeps track of its journal directory. That's the only way to make this
robust: don't clean it up triggered on time, but closely bound to the
algorithm that might fill it up.
sd-journald is a bit different: it is always around, and is important
for security, so normal "cooperative" cleanup rules don't apply to it.
OTOH, there are many user space caches (browser cache, image viewers'
thumbnails, downloads, format conversions) that could be cleaned up
periodically with an overall benefit to the health of the system.

I know that doing this properly and securely is hard... but I think
that current tools don't really cover this.

Zbyszek
Lennart Poettering
2015-04-13 14:02:19 UTC
Permalink
Post by Zbigniew Jędrzejewski-Szmek
Post by Lennart Poettering
Now, of these the first item is a work-around for broken daemons, and
this should really be better fixed in the daemons themselves. A daemon
that does not require tmpfiles is a good daemon. The third item is a
work-around against really broken semantics of X11, that cannot really
be fixed without breaking compat... But this issue is certainly not
something new code will fall for (hopefully)... The fourth item is a
work-around for broken semantics of UNIX, where files cannot be bound
to proper lifecycles of other objects, such as processes... "Aging"
these dirs is actually really nasty, since its cleanups are in no way
bound to the actual algorithms creating the files: code that generates
a lot of files in a short time, will be cleaned up only much later,
when the tmpfiles job happens to runs again...
But /tmp is also used for shared state (between services, but also
between different applications run by the same user, different
sessions of the same user, etc.).
Not really. Shared state is what /run is for really.

Note that we kinda encourage all services to set PrivateTmp=, and
consider daemons which need a shared /tmp to be a thing of the past,
that should better be fixed.

If you want to pass files in /tmp around, that's fine, but it's almost
certainly something where aging is the wrong answer. I much better
lifecycle management for files in /tmp could be something like a
O_TMPFILE that however keeps the filenames in the directory visible as
long as the file is opened. i.e. a scheme where a file is deleted the
moment the last fd is closed for it, but until then is a normal file
with a filename and everything, where the filename can be used to
create additional fds, and all.
Post by Zbigniew Jędrzejewski-Szmek
Such files are not bound to any process, or any session, and should
not be. For example, when I download stuff I often stick it in /tmp,
so that it stays around if I need it, but goes away without me
taking any concious action after some time. Gnome's thumbnails are
a bit like this: they are not bound to the life cycle of anything,
we just want them to go away when they have not been used for a
while.
I very much disagree. Especially the thumbnailing thing is something
where the clean-up should be primarily bound to size on disk
constraints, and tmpfiles really cannot help with size on disk...

Doing this based on aging via tmpfiles would be a hack, that people
might resort to only because proper size-based cleanup is missing.
Post by Zbigniew Jędrzejewski-Szmek
The application which creates thumbnails (or other similar caches)
*should* take care to not use to much space when creating things rapidly.
I assume that gnome does that already. But the application cannot really
implement good time based cleanup, especially that time based cleanup
is especially useful when the application is *not* running.
I am not sure what benefit it would be to have time-based clean-up for
this. Enforcing a disk space limit, plus replacement in LRU style
would make sense, but there's little point in deleting old entries
really.

And even if we say that time-based clean-up would be useful: the
*primary* logic should *still* be about disk space limits, nothing
else. And if you implement that in the thumbnailer, then you should
also implement the time-based cleanups.

Let's not forget that tmpfiles is actually a really dumb thing. It
looks at the file dates only, and has no idea at all about how files
fit together. It will remove individual files with completely
disregard of how they fit in the big picture, and related to other
files. Such a scheme is OK for cases like temporary files in /tmp,
since every file there probably can be considered independently of all
others. But for things like the thumbnailing it might actually not be
true at all...
Post by Zbigniew Jędrzejewski-Szmek
Post by Lennart Poettering
Hence, if this is done at all, it really should be the user's code
that runs this, not the system code.
Well, the whole discussion started with the fact that this cannot be
implemented as user code without being crippled.
Which kinda indicates that we probably shouldn't be doing that all ;-)

Lennart
--
Lennart Poettering, Red Hat
Lennart Poettering
2015-04-12 17:24:32 UTC
Permalink
I'm wondering if we should provide better per-user tmpfiles support.
For example, if we allowed a set of "user" tmpfiles, which would
be executed by the system instance, but would be considered relative to
the home directory and XDG_RUNTIME_DIR (~ or %h to refer to the home directory,
%t to XDG_RUNTIME_DIR, ...). We would execute that for every user.
Which makes me wonder again, why tmpfiles.d was never implemented in the
way all other units are implemented.
Currently, it's impossible to declare a dependency of a service upon a
tmpdir, which feels out of line with the way things are usually handled
in a systemd-based system.
OpenVPN requires /run/openvpn/ to exist before being able to start.
This leads to the following possible scenarios to make OpenVPN usable on
a system where OpenVPN was just installed (and there was no reboot to
It should just create the dir on its own. Invoking the mkdir() syscall
is hardly the most complex thing in the world. If it's really about
just this dir, it's certainly easier to make openvpn just invoke one
more syscall than to add a tmpfiles snippet an RPM scriplet invocation
and whatnot else. Also, it's much easier for everybody to grok, and
the thing will be a ton more robust...
- creation of tmpfile directories is left to the application (again
duplicated effort and the wrong place to do it, when there is a
centralized mechanism for handling this properly)
I strongly disgaree. Invoking "mkdir()" is trivial, openvpn really
should do that. (unless it always runs unrpivileged, see below)
are there any real technical/conceptual reasons, why tmpfiles.d handling
wasn't implemented in the "systemd unit" way which would allow a service
to depend on the correct state of one or more tmpfiles.d items, so on
each service startup, the existence + state of the required directories
would be verified and ensured.
We have RuntimeDirectory= as a native unit setting. However, it is
only really useful for daemons that run unprivileged all the time
(i.e. also use User= or so), and cannot create the directory on their
own. For all others: they really should create their runtime dirs on
their own. Don't bother with tmpfiles for no reason, please...

Lennart
--
Lennart Poettering, Red Hat
Continue reading on narkive:
Loading...