Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
The Politics of systemd Part 2
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3 ... 23, 24, 25 ... 27, 28, 29  Next  
This topic is locked: you cannot edit posts or make replies.    Gentoo Forums Forum Index Gentoo Chat
View previous topic :: View next topic  
Author Message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6356

PostPosted: Tue Feb 28, 2017 8:40 pm    Post subject: Reply with quote

Zucca wrote:
Currently (upstream) programs should try to create their temporary files by themselves.

No, they should not!
To create/clean temporary files/dirs and to set their permissions appropriately, you have to be root!
It would be extremely stupid if a program which should actually run with certain user permissions into a SUID program, only because it might be necessary to generate tmpfile directories for the corresponding user as root.
It is much more secure to have only one program doing this tmpfiles setup for all programs than to let each program do it separately as root, each with its own possible attack vector.
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6227
Location: Room 101

PostPosted: Wed Mar 01, 2017 7:59 am    Post subject: Reply with quote

Zucca wrote:
Out of curiosity, I'd like to know if opentmpfiles is a bad thing, then why it is? Enlighten me.

Zucca ... to answer that question a prior question needs to be posed: why is tempfiles.d needed at all? The answer to that is that it is due to the fact that /var/run became tmpfs, but, again, we need to ask the question: why?

Wikipedia: Filesystem_Hierarchy_Standard wrote:
Modern Linux distributions include a /run directory as a temporary filesystem (tmpfs) which stores volatile runtime data, following the FHS version 3.0. According to the FHS version 2.3, such data were stored in /var/run but this was a problem in some cases because this directory is not always available at early boot. As a result, these programs have had to resort to trickery, such as using /dev/.udev, /dev/.mdadm, /dev/.systemd or /dev/.mount directories, even though the device directory isn't intended for such data.

So you might say one problem was "solved" by creating another (given that the majorty of services expecting a directory structure under /var/run, and so requiring tempfiles.d, are not involved in "early boot").

mv wrote:
Zucca wrote:
Currently (upstream) programs should try to create their temporary files by themselves.

No, they should not! To create/clean temporary files/dirs and to set their permissions appropriately, you have to be root! It would be extremely stupid if a program which should actually run with certain user permissions into a SUID program, only because it might be necessary to generate tmpfile directories for the corresponding user as root. It is much more secure to have only one program doing this tmpfiles setup for all programs than to let each program do it separately as root, each with its own possible attack vector.

mv ... no, daemons do this all the time, take the following as an example:

ls -ld /var/run/*(/):
drwx------  2 root     root      40 2017-02-24 19:45 /var/run/alsasound/
drwx------  2 root     root      80 2017-02-24 19:45 /var/run/blkid/
drwxr-xr-x  2 dnscrypt dnscrypt  60 2017-03-01 06:11 /var/run/dnscrypt-proxy/
drwxrwxr-x  2 root     uucp     100 2017-03-01 08:40 /var/run/lock/
drwxr-xr-x  2 root     root      60 2017-02-24 19:45 /var/run/mount/
drwxrwxr-x 14 root     root     380 2017-03-01 06:11 /var/run/openrc/
drwxr-x---  2 root     wheel     60 2017-03-01 06:11 /var/run/wpa_supplicant/

... these are all "created" by the services, or applications, themselves (no tempfiles.d is involved). None of these are suid, they are system daemons (for the most part), and are run from init. What particular applications are you thinking of that need to create directories under /var/run that would need to be made suid in order to function without tempfiles.d?

best ... khay
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6356

PostPosted: Wed Mar 01, 2017 3:37 pm    Post subject: Reply with quote

khayyam wrote:
no, daemons do this all the time

I repeat the part of your cited sentence which you have ignored:
mv wrote:
a program which should actually run with certain user permissions

Daemons are usually no such programs (and even if they drop certain permissions after being daemonized, they are obviously very exceptional by being run by root and not by the user who actually wants to use them).
Quote:
What particular applications are you thinking of

All applications which need to access (and manipulate) data common to all of its users: TeX or other programs using common fonts (which they generate) or precompiled formats, games saving highscores, possibly global editor/browser/whatever preferences, many other database applications, portage, eix, ccache, ...
Back to top
View user's profile Send private message
CasperVector
Apprentice
Apprentice


Joined: 03 Apr 2012
Posts: 155

PostPosted: Wed Mar 01, 2017 4:01 pm    Post subject: Reply with quote

mv wrote:
All applications which need to access (and manipulate) data common to all of its users: TeX or other programs using common fonts (which they generate) or precompiled formats, games saving highscores, possibly global editor/browser/whatever preferences, many other database applications, portage, eix, ccache, ...

All your examples are persistent storage, which are inappropriate for /var/run or /run; for shared resources that are intended to be wiped on reboot, a mix of mkdir / chown / chmod in correspondent init scripts are usually adequate.
_________________
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C


Last edited by CasperVector on Thu Mar 02, 2017 1:19 am; edited 1 time in total
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6227
Location: Room 101

PostPosted: Wed Mar 01, 2017 4:46 pm    Post subject: Reply with quote

mv wrote:
khayyam wrote:
What particular applications are you thinking of that need to create directories under /var/run that would need to be made suid in order to function without tempfiles.d?

All applications which need to access (and manipulate) data common to all of its users: TeX or other programs using common fonts (which they generate) or precompiled formats, games saving highscores, possibly global editor/browser/whatever preferences, many other database applications, portage, eix, ccache, ...

mv ... that is an entirely different question (quote unexpergated), we are talking about /var/run (or more precisely /run) which, by becoming tmpfs, required a tempfiles.d implimentation.

best ... khay
Back to top
View user's profile Send private message
Zucca
Veteran
Veteran


Joined: 14 Jun 2007
Posts: 1798
Location: KUUSANKOSKI, Finland

PostPosted: Wed Mar 01, 2017 6:50 pm    Post subject: Reply with quote

What I'm getting wrong if a program ran by non-root can make temporary files without tmpfiles?
It can create those under /tmp or under /run/user/$UID. /run/user/$UID -directory can be created during boot by root, but that's it. All the rest are done by non-root. It does not need tmpfiles and for compability shoud use /tmp if possible.
tmpfiles is very handy tool, but I think programs should not depend on it (unless they can "probe" for it).
_________________
..: Zucca :..

Code:
ERROR: '--failure' is not an option. Aborting...
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 15586

PostPosted: Thu Mar 02, 2017 2:29 am    Post subject: Reply with quote

Yes, non-root programs can make their own temporary files. However, what do you do if you need a program to create a temporary file with a well-known name and you cannot allow other users to intentionally collide with that name? For example, recent versions of GnuPG lost the ability to run without an agent, so now it always creates the agent if one is not running. It prefers to create its socket at a well-known path under /run/user/$UID, but absent that, it will drop it in $HOME/.gnupg, and if that fails, it is completely broken. I ran into this on a system which had no /run/user and had $HOME mounted read-only. GnuPG was completely unusable because it demanded an agent (even for simple things that older versions could do without an agent), could not write to /run/user/$UID (directory did not exist), and could not write to $HOME (due to read-only mount).

Any directory which is world-writable runs the risk that the wrong user will create a well-known name, so /run/user cannot be made world-writable, nor can GnuPG agent safely fall back to using /tmp. Using tmpfiles, or a feature like it, enables root to pre-create, with proper ownership and permissions, directories that user programs can then rely on.
Back to top
View user's profile Send private message
roki942
Apprentice
Apprentice


Joined: 18 Apr 2005
Posts: 285
Location: Seattle

PostPosted: Thu Mar 02, 2017 2:38 am    Post subject: Reply with quote

223 is out https://github.com/systemd/systemd/blob/master/NEWS
Will there be more fallout from this?
Quote:
* DBus policy files are now installed into /usr rather than /etc. Make
sure your system has dbus >= 1.9.18 running before upgrading to this
version, or override the install path with --with-dbuspolicydir= .
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6356

PostPosted: Thu Mar 02, 2017 4:21 am    Post subject: Reply with quote

khayyam wrote:
we are talking about /var/run

No, we are talking about the purpose of tmpfiles.d which is of course not subject to this restriction which you just invented now.
Usually, /var/tmp and /var/cache are not cleaned on reboot, but this does neither mean that applications should break on reboot if they are nor that applications should be reliable for creating directories there with appropriate permissions:
Gentoo has since quite a while the policy that these are allowed to be on non-persistent (or less-persistent) storage.
This is a very reasonable policy for many reasons (e.g. these are typical directories which you will usually exclude from backups).

But even with the restriction "only in /var/run" what I said is true: Every program which has no other reason to be run only as root than that it needs a user-independent file/directory/socket name should better rely on the tmpfiles.d mechanism than relying on being run as root. For examples, just look into /usr/lib/tmpfiles.d. In my case, it contains sudo, screen, eix, gentoolkit, pdnsd, openvpn, tlsdate, tor and others, and I hope that many further projects will follow this sane policy.
Also the files from systemd which I find there which generate persistent names like /.tmp/.{X11,ICE,XIM,font,Test}-unix are very sane, because this avoids the risk of certain well-known symlink attacks unless the corresponding applications are carefully written by security specialists.

Well, of course, one could write in init.d units commands to create such directories/files/sockets or clean up data, and previously (and sometimes still) this was/is done. But it is much more convenient and consistent to just have one unit do this. Also, this way projects can use such things distribution independent, and ebuilds can install such "typical" things without having to introduce an init-system specific module. This is of course the reason why opentmpfiles has been separated from openrc: So you can use this de-facto standard with any init system conveniently. It is exactly a step in making gentoo independent of systemd.
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6227
Location: Room 101

PostPosted: Thu Mar 02, 2017 7:53 am    Post subject: Reply with quote

mv wrote:
khayyam wrote:
we are talking about /var/run

No, we are talking about the purpose of tmpfiles.d which is of course not subject to this restriction which you just invented now.

mv ... no, it's explicit in my first post on the subject, as I stated, tempfiles.d is a product of /var/run becoming tmpfs, the fact that tempfiles.d is now "the solution" for handling everything now considered "volatile" only points to how pervasive such a "solution" is.

mv wrote:
Usually, /var/tmp and /var/cache are not cleaned on reboot, but this does neither mean that applications should break on reboot if they are nor that applications should be reliable for creating directories there with appropriate permissions: Gentoo has since quite a while the policy that these are allowed to be on non-persistent (or less-persistent) storage. This is a very reasonable policy for many reasons (e.g. these are typical directories which you will usually exclude from backups).

I'm not sure I should read this as a claim there was a longstanding problem with such data, or that the added capability is somehow more robust than it once was. Whatever the case, I can't agree that this is an improvement because I've yet to identify a problem (so, discounting the "should break on reboot", or some supposed issues creating backups).

mv wrote:
But even with the restriction "only in /var/run" what I said is true: Every program which has no other reason to be run only as root than that it needs a user-independent file/directory/socket name should better rely on the tmpfiles.d mechanism than relying on being run as root. For examples, just look into /usr/lib/tmpfiles.d. In my case, it contains sudo, screen, eix, gentoolkit, pdnsd, openvpn, tlsdate, tor and others, and I hope that many further projects will follow this sane policy.

Which begs the question: what did we do before these features came to pass? Were eix, gentoolkit, pdnsd, screen, tor, etc, suid (as per your "[i]t would be extremely stupid if a program which should actually run with certain user permissions into a SUID program, only because it might be necessary to generate tmpfile directories")? I'm not disputing the issues involved (ie, those Hu pointed out in his example, or the fact that programs will have expectations about what exists on the filesystem) I'm disputing the solution provided (and, perhaps more importantly, how we got here).

mv wrote:
Also the files from systemd which I find there which generate persistent names like /.tmp/.{X11,ICE,XIM,font,Test}-unix are very sane, because this avoids the risk of certain well-known symlink attacks unless the corresponding applications are carefully written by security specialists.

I have a number of issues with that statement (ie, the "unless" proviso) but those aside, that is an issue of ACL's and it makes no difference to the subject of tempfiles.d.

mv wrote:
Well, of course, one could write in init.d units commands to create such directories/files/sockets or clean up data, and previously (and sometimes still) this was/is done. But it is much more convenient and consistent to just have one unit do this. Also, this way projects can use such things distribution independent, and ebuilds can install such "typical" things without having to introduce an init-system specific module. This is of course the reason why opentmpfiles has been separated from openrc: So you can use this de-facto standard with any init system conveniently. It is exactly a step in making gentoo independent of systemd.

Have to chuckle at that last sentence, but anyhow, I'm not buying that argument, the "problem" (if there was one) has now been surpassed by the solution.

best ... khay
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6356

PostPosted: Thu Mar 02, 2017 5:40 pm    Post subject: Reply with quote

khayyam wrote:
what did we do before these features came to pass?

I cannot speak for other projects, but eix had a big isue with this: eix-update (and also eix-sync) had contained a lot of clumsy code to create directories and files before dropping permissions. This was not only hard to maintain and simply ugly, it was also a permanent security risk, because it meant e.g. that a lot of stuff had to be done with root permissions (to find out where and how the directories should be created). With the introduction of tmpfiles.d and by relying on this mechanism all these hacks could finally be removed: Now the dropping of privileges is the first thing which most eix tools do (as soon as they know which privileges to use...).
For several of my tiny projects the situation is similar.
And why should e.g. tor or a dns reselver not immediately be run with reduced privileges? Only to generate sockets/dirs/files which some preparing script can do much safer?

Edit: I think, previously a lot of these things was just done by writing more clumsy openrc scripts: Instead of having a uniform format, every init-script author had reinvented the wheel. Very much like the classical sysv scripts contained bulks of copied code, because in the lack of a uniform framework, every script had to parse the "start"/"stop"/"restart" parameters independently.
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6227
Location: Room 101

PostPosted: Thu Mar 02, 2017 9:51 pm    Post subject: Reply with quote

mv wrote:
khayyam wrote:
what did we do before these features came to pass?

I cannot speak for other projects, but eix had a big isue with this: eix-update (and also eix-sync) had contained a lot of clumsy code to create directories and files before dropping permissions. This was not only hard to maintain and simply ugly, it was also a permanent security risk, because it meant e.g. that a lot of stuff had to be done with root permissions (to find out where and how the directories should be created).

mv ... if eix is writing to /var/cache/eix then the privileges to do so are required, and this hasn't changed with the advent of tmpfiles.d. Similarly, if /var/cache/eix is required, then this can be created as part of the install process. All that /usr/lib/tmpfiles.d/eix.conf (and so tempfiles.d) is doing is creating a single directory ... and that is no more/less secure than if it were done at install time. So, the argument that such "volatile" sections of the filesystem expose a "security risk" that tempfiles.d mitigates seems to me moot, we already have the means to deal with the "problem":

equery belongs -e /var/cache/man:
 * Searching for /var/cache/man ...
sys-apps/man-1.6g (/var/cache/man)

mv wrote:
With the introduction of tmpfiles.d and by relying on this mechanism all these hacks could finally be removed: Now the dropping of privileges is the first thing which most eix tools do (as soon as they know which privileges to use...).

So the creation of one single directory, which could be created at install time, amounts to "all these hacks"? You are overstating the problem so as to make the problem/solution seem greater than it actually is.

mv wrote:
And why should e.g. tor or a dns reselver not immediately be run with reduced privileges? Only to generate sockets/dirs/files which some preparing script can do much safer?

tempfiles.d is now creating sockets? Normally a dns resolver (or other service) requires increased privileges to bind to a port, if written with security in mind it then drops privileges, but none of this is relevant to tempfiles.d ... except that tempfiles.d is now required to create directories on filesystems which no longer survive reboots, and which these services expect to be there.

mv wrote:
Edit: I think, previously a lot of these things was just done by writing more clumsy openrc scripts: Instead of having a uniform format, every init-script author had reinvented the wheel. Very much like the classical sysv scripts contained bulks of copied code, because in the lack of a uniform framework, every script had to parse the "start"/"stop"/"restart" parameters independently.

Please provide examples/references, otherwise I'll take that as bunk. The most that would happen is "checkpath -d -m 0755 -o user:group /var/run/foo" and/or (perhaps) "if [ ! -d "$rundir" ] ; then mkdir -p -m 0750 "$rundir" ; fi", both of which would seem fairly standard, if not good practice.

best ... khay
Back to top
View user's profile Send private message
Zucca
Veteran
Veteran


Joined: 14 Jun 2007
Posts: 1798
Location: KUUSANKOSKI, Finland

PostPosted: Fri Mar 03, 2017 1:10 pm    Post subject: Reply with quote

roki942 wrote:
223 is out https://github.com/systemd/systemd/blob/master/NEWS
Will there be more fallout from this?
Quote:
* DBus policy files are now installed into /usr rather than /etc. Make
sure your system has dbus >= 1.9.18 running before upgrading to this
version, or override the install path with --with-dbuspolicydir= .
I suppose you can still have policy files under /etc. Those then override ones in /usr... I'd guess.
_________________
..: Zucca :..

Code:
ERROR: '--failure' is not an option. Aborting...
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 3426

PostPosted: Fri Mar 03, 2017 4:51 pm    Post subject: Reply with quote

Zucca wrote:
roki942 wrote:
223 is out https://github.com/systemd/systemd/blob/master/NEWS
Will there be more fallout from this?
Quote:
* DBus policy files are now installed into /usr rather than /etc. Make
sure your system has dbus >= 1.9.18 running before upgrading to this
version, or override the install path with --with-dbuspolicydir= .
I suppose you can still have policy files under /etc. Those then override ones in /usr... I'd guess.


It's entirely possible that I'm reading too much into this, and getting my exercise by jumping to conclusions, but...

/usr is for package owners - upstream.
/etc is for distribution owners and the end-user sysadmins.

Moving configuration from /etc to /usr could be taken as a sign that upstream wishes to control policy.

In a slightly less sinister interpretation, systemd is largely about containers and containerized "stateless" systems, in which case /etc makes less and less sense, because it's wiped when a container is wiped. This is another step in the corporate/upstream-owned machine.
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6356

PostPosted: Sat Mar 04, 2017 5:27 pm    Post subject: Reply with quote

khayyam wrote:
If eix is writing to /var/cache/eix then the privileges to do so are required

Sure, but these are much lower than the privileges required to write to /var/cache which is what would have to be done without relying on tmpfiles.d
Quote:
Similarly, if /var/cache/eix is required, then this can be created as part of the install process.

Exactly: Relying on something else to create the directory. Whether it is tmpfiles.d or something else is not important, but tmpfiles.d is a way in which it works without problems, even if /var/cache should have been erased for one reason or another.
Quote:
You are overstating the problem so as to make the problem/solution seem greater than it actually is.

You are trying to shrink an actual existing problem, because it does not match in your holy war that a meanwhile adopted standard is actually useful despite it was first introduced by somebody related with systemd. We are just talking about a simple script which produces a sane configuration on system startup, according to the requests of the actually installed packages. The important thing is that this is now de fact standardized across all distributions: Only in this way the individual package authors can really rely on this.
Quote:
tempfiles.d is now creating sockets?

Sure. It can create directories with appropriate permissions for the socket files, but if requested, it can also directly create character devices or fifos.
Quote:
Please provide examples/references, otherwise I'll take that as bunk

I don't need references to see that all the classical init-files (not of openrc) contained bulks of identical code to deal with start/stop parameters: Every single such file is a proof of this trivial fact.

I'll leave now again alone with your holy war: The technical arguments have been said, and I am not interested in your fight against windmills.
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6356

PostPosted: Sat Mar 04, 2017 5:49 pm    Post subject: Reply with quote

depontius wrote:
It's entirely possible that I'm reading too much into this

You do ;)
Quote:
/usr is for package owners - upstream.
/etc is for distribution owners and the end-user sysadmins.

Moving configuration from /etc to /usr could be taken as a sign that upstream wishes to control policy.

No, the configuration is not moved to /usr. The fallback configuration (if nothing is requested by the admin or distribution in /etc) is moved to /usr. This makes perfectly sense, because it allows package authors to write the defaults which look reasonable to their packages; the distribution can simply adapt it to the distribution's requirement (overriding upstream choices directly in /usr), and the admin finally can override in /etc whatever he wishes.
This has nothing to do with upstream's wishes to control policy (BTW: Upstream is any packag author - typically not related to systemd) but more with upstream's wishes to provide an experience of a package which works "out of the box" even if a distribution should not (yet) have included that package fully in their repository.

Indeed, this mechanism is an alternative to Gentoo's etc-update mechanism (almost no distribution has the latter, anyway). Actually, I find it more convenient than etc-update, because as an administrator you can immediately see what you have locally changed, and you can also see the upstream's (or the distribution's) default configuration if you need to: Both is not so simple with etc-update unless you document it on your own or use version control or other not-so-easy means.

If I remember all the time which I spent with merging new configurations for ssh or tor or privoxy: It would be much simpler if I could say: Take automatically all of upsstream's configuration, but change only always this and that...
Quote:
In a slightly less sinister interpretation, systemd is largely about containers and containerized "stateless" systems

I don't object that this is another advantage of this mechanism. Actually, I do not see any disadvantage in the mentioned mechanism over etc-update except that it might be harder to detect upstream's changes. But ths is only a matter of adapting CONFiG_PROTECT: This gives you the best from both worlds.
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6227
Location: Room 101

PostPosted: Sun Mar 05, 2017 12:08 am    Post subject: Reply with quote

mv wrote:
khayyam wrote:
If eix is writing to /var/cache/eix then the privileges to do so are required

Sure, but these are much lower than the privileges required to write to /var/cache which is what would have to be done without relying on tmpfiles.d

mv ... bunk, the reason I followed that statement with "this can be created as part of the install process" was to counter your "[...] clumsy code to create directories [...] a permanent security risk" and to show that there is nothing happening here which tempfiles.d mitigates.

mv wrote:
khayyam wrote:
Similarly, if /var/cache/eix is required, then this can be created as part of the install process.

Exactly: Relying on something else to create the directory. Whether it is tmpfiles.d or something else is not important, but tmpfiles.d is a way in which it works without problems, even if /var/cache should have been erased for one reason or another.

No, the point in the above is that the directory structure can be created as part of the install process, which is not something eix does but which you have argued then requires "clumsy code" to do so, and how much less a "permanent security risk" to have tempfiles.d do this.

mv wrote:
khayyam wrote:
You are overstating the problem so as to make the problem/solution seem greater than it actually is.

You are trying to shrink an actual existing problem, because it does not match in your holy war that a meanwhile adopted standard is actually useful despite it was first introduced by somebody related with systemd. We are just talking about a simple script which produces a sane configuration on system startup, according to the requests of the actually installed packages. The important thing is that this is now de fact standardized across all distributions: Only in this way the individual package authors can really rely on this.

Only in this case a "holy war" amounts to asking reasonable questions about why a particular "problem" exists, or what sort of "problem" it is (it's size, complexity, etc), and countering the bunk that is then provided to validate the claimed "solution". The fact that in this particular case you need only create a directory as part of the install process and your "sane configuration" is in place, and "permanent security risk" mitigated, is so completely loony as to be a "holy war".

mv wrote:
khayyam wrote:
tempfiles.d is now creating sockets?

Sure. It can create directories with appropriate permissions for the socket files, but if requested, it can also directly create character devices or fifos.

Of course a script can create any type of required file, the point is, what purpose does it serve for tempfiles.d to do this ... other than the added "security" of having a root process do it, as opposed to something that might pose a "permanent security risk"?

mv wrote:
khayyam wrote:
Please provide examples/references, otherwise I'll take that as bunk

I don't need references to see that all the classical init-files (not of openrc) contained bulks of identical code to deal with start/stop parameters: Every single such file is a proof of this trivial fact.

I see, so we are now talking about "classical init-files" even though in what I was replying to you stated: "previously a lot of these things was just done by writing more clumsy openrc scripts: Instead of having a uniform format, every init-script author had reinvented the wheel" ... way to shift goal posts.

mv wrote:
I'll leave now again alone with your holy war: The technical arguments have been said, and I am not interested in your fight against windmills.

Yes, please do leave me alone, your "technical arguments" basically amount to nothing.

best ... Don Quixote
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Sun Mar 05, 2017 1:56 pm    Post subject: Reply with quote

Hu wrote:
Yes, non-root programs can make their own temporary files. However, what do you do if you need a program to create a temporary file with a well-known name and you cannot allow other users to intentionally collide with that name? For example, recent versions of GnuPG lost the ability to run without an agent, so now it always creates the agent if one is not running. It prefers to create its socket at a well-known path under /run/user/$UID, but absent that, it will drop it in $HOME/.gnupg, and if that fails, it is completely broken. I ran into this on a system which had no /run/user and had $HOME mounted read-only. GnuPG was completely unusable because it demanded an agent (even for simple things that older versions could do without an agent), could not write to /run/user/$UID (directory did not exist), and could not write to $HOME (due to read-only mount).

Any directory which is world-writable runs the risk that the wrong user will create a well-known name, so /run/user cannot be made world-writable, nor can GnuPG agent safely fall back to using /tmp. Using tmpfiles, or a feature like it, enables root to pre-create, with proper ownership and permissions, directories that user programs can then rely on.

Eh, this is simply an argument for environment variables to override defaults, and indeed gpg and gpg-agent use GNUPGHOME.

It's important to separate standard (run by user, as the user) programs from system daemons (which are often run as a specific user-acct.)
Nothing we're discussing that is tricky is about the standard program case, only about shared, system-wide resources.

I haven't seen anything yet that isn't answered by a standard mkdir -p call in an initscript (which also allows for the possibility of more flexibility.)

No need to check if it exists first: mkdir -p won't fail in that case, only if unable to create a needed path.

I agree with khayyam wrt install-time setup; either way the program doesn't need to bother, just bail out with a suitable error message.
If the author wants to try making the directory first, that's up to them. *shrug*
Back to top
View user's profile Send private message
Tony0945
Advocate
Advocate


Joined: 25 Jul 2006
Posts: 3848
Location: Illinois, USA

PostPosted: Sun Mar 05, 2017 3:07 pm    Post subject: Reply with quote

I've been following this tmpfiles discussion with interest. I've been looking at the code and it seems this "daemon" (actually two soi-disant daemons) aren't really daemons. They run once and end. In both cases they call the same shell script with different parameters. The int script is only to make sure that the call is done at the correct time, the first time immediately after mount, the second time immediately before dev. IMHO, the daemons should be junked and the mount and dev init scripts modified to call the common sh script, perhaps optionally via a variable in the respective "conf.d "'s.

The more I look at this Red Hat code, the more it looks like their penchant is to replace Linux with another OS running on top of Linux. Bad design. Bad bad design.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 15586

PostPosted: Sun Mar 05, 2017 7:55 pm    Post subject: Reply with quote

At the risk of derailing this thread:
steveL wrote:
Hu wrote:
I ran into this on a system which had no /run/user and had $HOME mounted read-only. GnuPG was completely unusable because it demanded an agent (even for simple things that older versions could do without an agent), could not write to /run/user/$UID (directory did not exist), and could not write to $HOME (due to read-only mount).

Eh, this is simply an argument for environment variables to override defaults, and indeed gpg and gpg-agent use GNUPGHOME.
I agree that an environment variable is an adequate solution for this (perhaps we could call it $GPG_AGENT_INFO ;)), but $GNUPGHOME is not a solution to the problem I described. When present, that is used in place of computing $HOME/.gnupg; in my use case, the files for the public and secret keys are in the read-only GnuPG home directory and the socket must not be. If I set $GNUPGHOME, then it will search for the keys in the wrong place. If I do not set it, the socket will be created in the wrong place. To support the scenario I described, gnupg would need one variable to tell it where data files are stored and a separate variable to control where its automatic socket is created. Alternately, the problem could be solved by a variable telling it I have no need of the agent and will happily accept not creating a Unix domain socket at all.
Back to top
View user's profile Send private message
CasperVector
Apprentice
Apprentice


Joined: 03 Apr 2012
Posts: 155

PostPosted: Mon Mar 06, 2017 1:26 am    Post subject: Reply with quote

Hu wrote:
To support the scenario I described, gnupg would need one variable to tell it where data files are stored and a separate variable to control where its automatic socket is created. Alternately, the problem could be solved by a variable telling it I have no need of the agent and will happily accept not creating a Unix domain socket at all.

Even when this has not been implemented in gpg, isn't your problem solvable by simply executing `install -d -o $gpguser -g $gpggrp -m 0700 /run/user/$gpguser' in a /etc/local.d script?
_________________
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 15586

PostPosted: Mon Mar 06, 2017 1:39 am    Post subject: Reply with quote

Yes, once I figured out that gpg would use that directory. The error message complained about the read-only $HOME and made no mention of support for /run/user/$UID. I had to figure that out by reading the source.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Mon Mar 06, 2017 12:55 pm    Post subject: Reply with quote

Hu wrote:
I ran into this on a system which had no /run/user and had $HOME mounted read-only. GnuPG was completely unusable because it demanded an agent (even for simple things that older versions could do without an agent), could not write to /run/user/$UID (directory did not exist), and could not write to $HOME (due to read-only mount).

steveL wrote:
Eh, this is simply an argument for environment variables to override defaults, and indeed gpg and gpg-agent use GNUPGHOME.

Hu wrote:
I agree that an environment variable is an adequate solution for this (perhaps we could call it $GPG_AGENT_INFO ;)), but $GNUPGHOME is not a solution to the problem I described. When present, that is used in place of computing $HOME/.gnupg; in my use case, the files for the public and secret keys are in the read-only GnuPG home directory and the socket must not be. If I set $GNUPGHOME, then it will search for the keys in the wrong place. If I do not set it, the socket will be created in the wrong place. To support the scenario I described, gnupg would need one variable to tell it where data files are stored and a separate variable to control where its automatic socket is created.

I wasn't sure if you were joking about GPG_AGENT_INFO above, as that is precisely the environment variable used for that. Or you can use the --gpg-agent-info cli option to override.

See man gpg, end of FILES (should be an ENVIROMENT VARIABLES section, but meh.)

Hmm I might be missing something in that it needs the pid set.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 15586

PostPosted: Tue Mar 07, 2017 3:00 am    Post subject: Reply with quote

Sorry, I should mark my mockery more clearly. Per the GnuPG 2.1 README:
gnupg-2.1.15/README:
* MIGRATION from 1.4 or 2.0 to 2.1

...

  Note that gpg-agent now uses a fixed socket.  All tools will start
  the gpg-agent as needed.  The formerly used environment variable
  GPG_AGENT_INFO is ignored by 2.1.  The SSH_AUTH_SOCK environment
  variable should be set to a fixed value.
Since they removed support for using that environment variable in its prior capacity (and with it, the ability to use gpg in an environment with a read-only $GNUPGHOME (unless the system administrator knows to create a /run/user/$UID on your behalf)), I sarcastically suggested that it is now free to be reused to tell the gpg-agent where to store its socket (such as a manually created directory under $TMPDIR). ;)
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6356

PostPosted: Tue Mar 07, 2017 8:46 am    Post subject: Reply with quote

Sorry to enter discussion again, but this argument shows that I had not been understood:
CasperVector wrote:
simply executing `install -d -o $gpguser -g $gpggrp -m 0700 /run/user/$gpguser' in a /etc/local.d script?

What is simpler:
/etc/local.d/my-gpg wrote:
#!/bin/sh
install -d -o me -g mygroup -m 0700 /run/user/me

or
/etc/tmpfiles.d/my-gpg.conf wrote:
d /run/user/me 0700 me mygroup - -

and what have you gained if you do the former instead of the latter?
You rely on a non-official but de-facto standard /etc/local.d instead of relying on a non-official but de-facto standard /etc/tmpfiles.d.
If you also start gpg earlier, the former might give you also dependency issues, because local.d is usually started last

If you are a package author you must make sure to have no order issues. So here the alternatives are: Provide init files for all init-systems (no matter whether the stuff is actually started) or rely that the distribution packager or local system admin really carefully reads the documentation and does it, or provide the one single file? Which increases the chance that the user will have a good experience with your package?

And what is wrong with /etc/tmpfiles.d? Does it cause heavy dependencies and give possible security problems? Are there any reasons to reject it?

There is only one reason to reject it: NIH
Back to top
View user's profile Send private message
Display posts from previous:   
This topic is locked: you cannot edit posts or make replies.    Gentoo Forums Forum Index Gentoo Chat All times are GMT
Goto page Previous  1, 2, 3 ... 23, 24, 25 ... 27, 28, 29  Next
Page 24 of 29

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum