Re: [systemd-devel] SystemD, Gnome permission problems
On Mon, 13.04.15 02:37, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > > 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. > 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. > 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... > > 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SystemD, Gnome permission problems
On Sun, Apr 12, 2015 at 07:19:07PM +0200, Lennart Poettering wrote: > On Sun, 12.04.15 14:11, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > > > 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... 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] > 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. > 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. > > 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 viewe
Re: [systemd-devel] SystemD, Gnome permission problems
Elias Probst schrieb: > On 04/12/2015 05:47 PM, Kai Krakow wrote: >> Elias Probst schrieb: >> >>> On 04/12/2015 04:11 PM, Zbigniew Jędrzejewski-Szmek wrote: 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. >>> >>> For example: >>> 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 >>> trigger tmpfiles.d creation) yet: >>> >>> 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... > 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. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SystemD, Gnome permission problems
On Sun, 12.04.15 16:46, Elias Probst (m...@eliasprobst.eu) wrote: > On 04/12/2015 04:11 PM, Zbigniew Jędrzejewski-Szmek wrote: > > 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. > > For example: > 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 > trigger tmpfiles.d creation) yet: 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SystemD, Gnome permission problems
On Sun, 12.04.15 14:11, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SystemD, Gnome permission problems
On 04/12/2015 05:47 PM, Kai Krakow wrote: > Elias Probst schrieb: > >> On 04/12/2015 04:11 PM, Zbigniew Jędrzejewski-Szmek wrote: >>> 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. >> >> For example: >> 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 >> trigger tmpfiles.d creation) yet: >> >> 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 signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SystemD, Gnome permission problems
Elias Probst schrieb: > On 04/12/2015 04:11 PM, Zbigniew Jędrzejewski-Szmek wrote: >> 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. > > For example: > 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 > trigger tmpfiles.d creation) yet: > > 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. ;-) -- Replies to list only preferred. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SystemD, Gnome permission problems
On 04/12/2015 04:11 PM, Zbigniew Jędrzejewski-Szmek wrote: > 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. For example: 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 trigger tmpfiles.d creation) yet: 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. This leads me to the question: 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. - Elias signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SystemD, Gnome permission problems
On Sun, Apr 12, 2015 at 03:41:31PM +0200, Lennart Poettering wrote: > On Sat, 11.04.15 16:21, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > > > On Sat, Apr 11, 2015 at 02:26:57PM +0200, Kai Krakow wrote: > > > dean schrieb: > > > > > > > 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). > > Yes, I figully agree... GNOME shouldn't bother with this, it's > actively harmful to do this. > > I file a bug now: > > https://bugzilla.gnome.org/show_bug.cgi?id=747737 Thanks. 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. 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. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SystemD, Gnome permission problems
On Sat, 11.04.15 16:21, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > On Sat, Apr 11, 2015 at 02:26:57PM +0200, Kai Krakow wrote: > > dean schrieb: > > > > > 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). Yes, I figully agree... GNOME shouldn't bother with this, it's actively harmful to do this. I file a bug now: https://bugzilla.gnome.org/show_bug.cgi?id=747737 Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SystemD, Gnome permission problems
On Sat, Apr 11, 2015 at 7:21 PM, Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote: > On Sat, Apr 11, 2015 at 02:26:57PM +0200, Kai Krakow wrote: > > dean schrieb: > > > > > 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. > 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. > 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SystemD, Gnome permission problems
On Sat, Apr 11, 2015 at 02:26:57PM +0200, Kai Krakow wrote: > dean schrieb: > > > 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SystemD, Gnome permission problems
dean schrieb: > 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. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SystemD, Gnome permission problems
On Sat, 2015-04-11 at 01:59 +0300, Mantas Mikulėnas wrote: > On Sat, Apr 11, 2015 at 1:57 AM, dean wrote: > 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. > > > 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. > > > -- > Mantas Mikulėnas 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? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SystemD, Gnome permission problems
On Sat, Apr 11, 2015 at 1:57 AM, dean wrote: > 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. > 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. -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
