Does Gentoo focus currently more on systemd?

[NeddySeagoon]

mv,

That's a good summary of the ML discussion.

I don't know if your post was intended that way, or even if your read the ML, but you have reached the same conclusions for the same reasons.

[Gatsby]

Essentially there was a flurry that opnetmpfiles was being removed due to security issues (issues that were known and were argued not as sever for well over a year and equally systemd-tmpfiles.d had a comparable issue [unsure if they resolved at the time]). News was pushed out, forum posts by devs... UNTIL it came out that basically the dev just didn't want to support it anymore

The dev (and apparently also the rest of opentmpfiles' developers) didn't want to support it anymore because he believed that fixing the security issue was too much work (among other things):

Here are my thoughts about opentmpfiles and systemd-tmpfiles.

• [...]
• opentmpfiles is vulnerable to a cve. I think mitigating this will take a complete rewrite in C.
• If we do rewrite in C, we are echoing work that has already been done in systemd-tmpfiles.
• I've been told that systemd-tmpfiles works fine on gentoo musl as well.
  [...]
• systemd-tmpfiles is part of the systemd tarball, but it runs fine standalone, like udev does.

Given this, I'm fine with systemd-tmpfiles for now since maintaining opentmpfiles feels like a lot of work without much benefit.

(source)
Do you believe that he is being dishonest?

Of course.
I don't trust him an inch.

EDIT: I only trust him regarding one thing: As long he is the "maintainer" of the openrc package, he will continue to cripple openrc in favour of systemd.

[NeddySeagoon]

Team,

Please stick to factual discussions.
When you post extraordinary claims, please cite extraordinary evidence.

I'm aware that opinions need have no basis in facts, but opinion based discussions around the merits of systemd invariably lead to the threads being locked.

[mv]

That's a good summary of the ML discussion.

I don't know if your post was intended that way[...]

I think that idea of just writing a tool in C is an interesting new point, because it reflects to the "one tool one job" idea of Unix. In fact, I was feeling encouraged again to write such a tool (as I previously thought about re-implementing systemd-tmpfiles), but then I remembered why such a tool was not already provided by standard unix tools: It is exactly because it cannot be provided by such "one tool one job" helpers: You really need to do all steps in C. And then practically, we are back at (almost) a full re-implementation in C. (And then indeed just the arguments against a full re-implementation hold for such a tool as well.)

[figueroa]

mv,

Then, once a full re-implementation has been created, tested, and deployed, the new package would need maintainer(s) forever; another straw on some poor camels back. Since this need is already being fulfilled well by an upstream project, there seems to be no compelling need for Gentoo to run it's own project.

As far as keeping the name systemd in the atom, which seems to be the major point of friction for some users, hiding the source of the project by renaming it to a something more winsome would be dishonest. In using a piece of the systemd project, it's good for us for the name to be in-our-face. I would rather that Gentoo developers not be encouraged to become sneaky in order to avoid unnecessary flak like this thread.

[szatox]

Yup, hiding the name and pretending it's something it is not wouldn't make it better.

Anyway, I had a look at some of those vulnerabilities listed earlier, and quite frankly I don't understand what is the purpose of tmpfiles and how it makes things safer and easier to manage. Right now it looks like a solution looking for a problem to me.

What is wrong with changes not being atomic? If root creates a directory for an application, this directory is owned by root and not writable to anyone else. It can also be created with arbitrary permissions before changing user and group to the application, which seems fine: nobody is able to modify the state half-way though the process anyway.

What's wrong with links in the path? We still have /var/run -> /run for example. If I wanted to put the pidfiles somewhere else, would it be actually wrong? Security is a process rather than a state; don't assume you can partially revoke any access you have ever granted to a user.

"Service stop" killing arbitrary processes via PID manipulation because pidfile is owned by application and can be modified to aim kill at any process in the system? That's because someone expected the service daemon to cooperate with init system instead of having start-stop-daemon do the job; I don't see how opentmpfs makes it better. Verifying the owner of the PID in question, or even invoking kill as the app user could help, but it's out of scope, isn't it?

There was something about changing ownership of the directory tree too, some permission escalation exploit.... If the directory already exists, and the owner/permissions don't match what the application wants, it's probably because root changed the ownership of permissions on that directory. And if root changed it, there was probably some reason behind it. Don't fix it, you damn windows, just log a warning if you want to be helpful

[mv]

What is wrong with changes not being atomic? If root creates a directory for an application, this directory is owned by root and not writable to anyone else.

This was all discussed before, but I am too lazy too look up the old threads:

Essentially, the thing is: As long as some additional assumptions are met, it is not a problem. These additional assumptions are essentially:

1. No untrusted process must run before tmpfiles.d is processed
2. All tmpfiles.d files are sane, e.g. involve only top-level directories like /tmp/subdir (not /tmp/subdir/exploitable-thingy), no recursive permission changes, etc.

A first glance, both assumptions appear safe to make for a gentoo/openrc-only system. But at second glance, they are not: Also for openrc, there are occasionally reasons to restart a service which (depending on the service) might re-execute a tmpfiles.d processing. Actually, usually even ebuilds process some tmpefiles.d so that they can function after installation and before a reboot. Moreover, not every package author is a security expert (and the idea of tmpfiles.d is that they need not be). Do you really want to manually inspect all tmpfiles.d files after every installation of a package and verify that they are sane? Are you experienced enough to judge this? Do you expect the same for every gentoo/openrc user?

If really both assumptions are violated together on a system, and an attacker knows this, they can produce a privilege escalation once they have an exploit to execute code as some user (the latter is usually relatively cheap to get as such vulnerabilities are relatively frequent). Perhaps one can construct also cases where already the violation of only one of the assumptions suffices for a privilege-escalation exploit.

[sam_]

What is wrong with changes not being atomic? If root creates a directory for an application, this directory is owned by root and not writable to anyone else.

This was all discussed before, but I am too lazy too look up the old threads:

Essentially, the thing is: As long as some additional assumptions are met, it is not a problem. These additional assumptions are essentially:

1. No untrusted process must run before tmpfiles.d is processed
2. All tmpfiles.d files are sane, e.g. involve only top-level directories like /tmp/subdir (not /tmp/subdir/exploitable-thingy), no recursive permission changes, etc.

A first glance, both assumptions appear safe to make for a gentoo/openrc-only system. But at second glance, they are not: Also for openrc, there are occasionally reasons to restart a service which (depending on the service) might re-execute a tmpfiles.d processing. Actually, usually even ebuilds process some tmpefiles.d so that they can function after installation and before a reboot. Moreover, not every package author is a security expert (and the idea of tmpfiles.d is that they need not be). Do you really want to manually inspect all tmpfiles.d files after every installation of a package and verify that they are sane? Are you experienced enough to judge this? Do you expect the same for every gentoo/openrc user?

If really both assumptions are violated together on a system, and an attacker knows this, they can produce a privilege escalation once they have an exploit to execute code as some user (the latter is usually relatively cheap to get as such vulnerabilities are relatively frequent).

Thanks. This is the point I tried to make earlier: it makes it a lot easier to safely write an init script and avoid footguns. And there's a pile of cases I gave earlier (non-exhaustive) where it would've at least partly helped.

[Anon-E-moose]

Would be interesting to see how many exploits actually happened with the old tmpfiles code vs the hubris.

It seems from all I've read, that this was just a theoretical problem, ie it might happen in the future

[mv]

Would be interesting to see how many exploits actually happened

This reminds me of some signature (wasn't it NeddySeagoon's one once?): There are two kind of people. Those who never lost data and those who make backups.

Sure, as long as you have not been exploited your security measurements were good enough.
Or have you just been lucky and nobody tried to exploit you with sufficiently many resources? Or maybe you have been exploited and do not know?

But I do not see why this should be any argument to keep known vulnerable code if you can replace it by code in which these vulnerabilities are known to be gone, which is not more complex than it need to be (I am speaking about systemd-tmpfiles, not about all of systemd), and which is meanwhile very well tested and for which since quite a while no security expert reported a vulnerability?

[sam_]

We generally don't wait for somebody to have their system actually compromised once a security vulnerability is reported. If we did, I'm confident we'd have a thread of rightly outraged and disappointed users. Esepcially given in this case, they often had Proof of Concepts (PoCs) attached anyway, so it's not like it was purely theoretical anyway.

[pietinger]

Would be interesting to see how many exploits actually happened with the old tmpfiles code vs the hubris.

It seems from all I've read, that this was just a theoretical problem, ie it might happen in the future

I dont know an exploit of this ... but ... it is the same principle as the exploit Microsoft has found with networkd-dispatcher (from systemd) here (I think you already know it):

https://www.microsoft.com/security/blog ... nimbuspwn/

So, it should be possible to exploit it, if it would be done insecure ...


(Info: I am an OpenRC-User and I "dont like" systemd ... but I have no problem with using parts of systemd IF they can help us)

[Anon-E-moose]

But I do not see why this should be any argument to keep known vulnerable code if you can replace it by code in which these vulnerabilities are known to be gone,

1st I didn't say anything about keeping code, I was talking about exploits and have no stand on replacing it, so try not to put me in the wrong camp

2nd the vulnerabilities might be fixed, it would require a complete code review to determine that, but even if it's true, are their other vulns?

I do know that many pieces of sys-d have security problems, but I don't see a massive stampede by devs or others to address those problems.
Not that it's surprising.

If an exploit has only been found in a lab, ie not in the wild, then it's theoretical.

Well, y'all have fun with the latest circle jerk

[sam_]

Would be interesting to see how many exploits actually happened with the old tmpfiles code vs the hubris.

It seems from all I've read, that this was just a theoretical problem, ie it might happen in the future

I dont know an exploit of this ... but ... it is the same principle as the exploit Microsoft has found with networkd-dispatcher (from systemd) here (I think you already know it):

https://www.microsoft.com/security/blog ... nimbuspwn/

So, it should be possible to exploit it, if it would be done insecure ...


(Info: I am an OpenRC-User and I "dont like" systemd ... but I have no problem with using parts of systemd IF they can help us)

Just to clarify again: networkd-dispatcher isn't a part of systemd (it's some sort of plugin or addon) and it's also not packaged in Gentoo even for systemd users.

[Naib]

Essentially there was a flurry that opnetmpfiles was being removed due to security issues (issues that were known and were argued not as sever for well over a year and equally systemd-tmpfiles.d had a comparable issue [unsure if they resolved at the time]). News was pushed out, forum posts by devs... UNTIL it came out that basically the dev just didn't want to support it anymore

The dev (and apparently also the rest of opentmpfiles' developers) didn't want to support it anymore because he believed that fixing the security issue was too much work (among other things):

Here are my thoughts about opentmpfiles and systemd-tmpfiles.

• [...]
• opentmpfiles is vulnerable to a cve. I think mitigating this will take a complete rewrite in C.
• If we do rewrite in C, we are echoing work that has already been done in systemd-tmpfiles.
• I've been told that systemd-tmpfiles works fine on gentoo musl as well.
  [...]
• systemd-tmpfiles is part of the systemd tarball, but it runs fine standalone, like udev does.

Given this, I'm fine with systemd-tmpfiles for now since maintaining opentmpfiles feels like a lot of work without much benefit.

(source)
Do you believe that he is being dishonest?

EXACTLY what happened with eudev, the reason it was created was twisted to be "oh its not needed anymore as systemd-udev supports musl" [...]

This wasn't said by some random Gentoo dev, it was the former eudev lead:

My original purpose for maintaining eudev was because systemd + musl did not play well together when udev was absorbed into the sytemd repo. Now thanks to patches from openembedded, they do, and my original reason for maintaining eudev is no longer valid. So its time to retire eudev. It has served its purpose as a stop-gap.

(source)

> Are there any concerns about upstream one day making udev and systemd
> inseparable again?

I can't address this. There are two issues: 1) making sure there is a device manager for musl. 2) making sure there is a device manager which is independent of systemd. My concern was the former, hence eudev. If one day I have to use systemd on a musl system, so be it. If anyone is concerned about the second issue, they are welcome to maintain eudev My life circumstances have changed and I don't have the time or will.

(source)
Do you believe that he is being dishonest?

The dev team were being dishonest yes.
The original news item was different and had to be recalled
https://archives.gentoo.org/gentoo-dev/ ... f7632e3ed6

That security issue had been around for well over a year and just sat there because the gentoo security team deemed it not as serious as it could have been. for the original news item to mark it for removal due to security concerns alone as is misleading

[pingtoo]

It seems from all I've read, that this was just a theoretical problem, ie it might happen in the future

I agree, this one of the over thinking engineer to believe there is a security issue for opentmpfiles on Gentoo

However I accept the argument that the developer of opentmpfiles wish to stop development and therefor adapt systemd-tmpfiles

I was intrigued by this thread, so I follow all links that relevant to this topic and did some thinking. I believe opentmpfiles is sufficient for Gentoo usage.

Here is my reason,

1. opentmpfiles on Gentoo usage is very different from how a systemd managed system. In a systemd managed system the *tmp files/directory* can happen in unpredictable manner because the dependency design.
   In Gentoo, there are only three place
   • sysinit service opentmpfiles-dev
   • boot service opentmpfiles-setup
   • A ebuild call restart service(s) or call tmpfiles directly
   All of three place require execute by root privilege. so if attacker can involve root privilege, the problem is not at opentmpfiles.
   In Gentoo opentmpfiles only check three place for configuration files
   • /usr/lib/tmpfiles.d
   • /run/tmpfiles.d
   • /etc/tmpfiles.d
   All these three places only root allow to write, All configuration file in those directories own by root and only root allow to change.
2. The openrc/opentmpfile issue CVE-2017-18925 root privilege escalation by symlink attack Really does not apply to Gentoo system.
   because if attacker can modify/create opentmpfiles configuration file as root, than the problem is at system user's privilege management, it is the not the tool.

[sam_]

Essentially there was a flurry that opnetmpfiles was being removed due to security issues (issues that were known and were argued not as sever for well over a year and equally systemd-tmpfiles.d had a comparable issue [unsure if they resolved at the time]). News was pushed out, forum posts by devs... UNTIL it came out that basically the dev just didn't want to support it anymore

The dev (and apparently also the rest of opentmpfiles' developers) didn't want to support it anymore because he believed that fixing the security issue was too much work (among other things):

Here are my thoughts about opentmpfiles and systemd-tmpfiles.

• [...]
• opentmpfiles is vulnerable to a cve. I think mitigating this will take a complete rewrite in C.
• If we do rewrite in C, we are echoing work that has already been done in systemd-tmpfiles.
• I've been told that systemd-tmpfiles works fine on gentoo musl as well.
  [...]
• systemd-tmpfiles is part of the systemd tarball, but it runs fine standalone, like udev does.

Given this, I'm fine with systemd-tmpfiles for now since maintaining opentmpfiles feels like a lot of work without much benefit.

(source)
Do you believe that he is being dishonest?

EXACTLY what happened with eudev, the reason it was created was twisted to be "oh its not needed anymore as systemd-udev supports musl" [...]

This wasn't said by some random Gentoo dev, it was the former eudev lead:

My original purpose for maintaining eudev was because systemd + musl did not play well together when udev was absorbed into the sytemd repo. Now thanks to patches from openembedded, they do, and my original reason for maintaining eudev is no longer valid. So its time to retire eudev. It has served its purpose as a stop-gap.

(source)

> Are there any concerns about upstream one day making udev and systemd
> inseparable again?

I can't address this. There are two issues: 1) making sure there is a device manager for musl. 2) making sure there is a device manager which is independent of systemd. My concern was the former, hence eudev. If one day I have to use systemd on a musl system, so be it. If anyone is concerned about the second issue, they are welcome to maintain eudev My life circumstances have changed and I don't have the time or will.

(source)
Do you believe that he is being dishonest?

The dev team were being dishonest yes.
The original news item was different and had to be recalled
https://archives.gentoo.org/gentoo-dev/ ... f7632e3ed6

That security issue had been around for well over a year and just sat there because the gentoo security team deemed it not as serious as it could have been. for the original news item to mark it for removal due to security concerns alone as is misleading

That doesn't answer the eudev part. Anyway, as for opentmpfiles, bug 751415, had no reply in Gentoo or on the upstream bug tracker. Undisputed vulnerabilities with no response or fix upstream are generally candidates for masking or last-rites/removal. Someone making an error, there being an oversight, or nobody bothering to explain from an opentmpfiles perspective why something is fine is not being dishonest.

[sam_]

It seems from all I've read, that this was just a theoretical problem, ie it might happen in the future

I agree, this one of the over thinking engineer to believe there is a security issue for opentmpfiles on Gentoo

However I accept the argument that the developer of opentmpfiles wish to stop development and therefor adapt systemd-tmpfiles

I was intrigued by this thread, so I follow all links that relevant to this topic and did some thinking. I believe opentmpfiles is sufficient for Gentoo usage.

Here is my reason,

1. opentmpfiles on Gentoo usage is very different from how a systemd managed system. In a systemd managed system the *tmp files/directory* can happen in unpredictable manner because the dependency design.
   In Gentoo, there are only three place
   • sysinit service opentmpfiles-dev
   • boot service opentmpfiles-setup
   • A ebuild call restart service(s) or call tmpfiles directly
   All of three place require execute by root privilege. so if attacker can involve root privilege, the problem is not at opentmpfiles.
   In Gentoo opentmpfiles only check three place for configuration files
   • /usr/lib/tmpfiles.d
   • /run/tmpfiles.d
   • /etc/tmpfiles.d
   All these three places only root allow to write, All configuration file in those directories own by root and only root allow to change.
2. The openrc/opentmpfile issue CVE-2017-18925 root privilege escalation by symlink attack Really does not apply to Gentoo system.
   because if attacker can modify/create opentmpfiles configuration file as root, than the problem is at system user's privilege management, it is the not the tool.

As mv said earlier, the problem is that:

• upstreams may provide their own tmpfiles configuration which works safely with systemd's implementation, yet doesn't with opentmpfiles
• it's unrealistic and unsustainable for everybody to have to audit both every file from upstream for compatibility and security with opentmpfiles
• if opentmpfiles has footguns that systemd's tmpfiles does not, it's introducing the problems that tmpfiles was trying to solve (avoiding footguns in init scripts by doing things at startup in a standard way)

Also, it being run as root doesn't really absolve anything. This is back to "it's better to make it easier to write a safe init script".

[Hu]

To add on to sam_'s remark, while root privilege may be required to install a dangerous opentmpfiles configuration, that does not mean a dangerous file cannot happen on a system that is otherwise free of malicious privileged users. An upstream developer without malicious intent may, through simple negligence, write and ship a tmpfiles.d configuration that, when processed by opentmpfiles, would be a security problem. Regardless of whether the file is dangerous because of malice or negligence, it may well look reasonable enough that it could pass a simple code review, and only be recognized as a problem when audited by someone who is specifically considering all the edge cases that an attacker might try to apply to it. In the general case, a security review must assume that every security property not guaranteed by the program under test will fail in the attacker's favor. In this situation, that would mean that an unprivileged user might have a full Linux shell running concurrent to the opentmpfiles code processing the bad configuration file. With full shell access, the attacker can make any system calls necessary to try to trip opentmpfiles bugs associated with race conditions.

Obtaining a quality code review is famously hard. Shipping a tool that enables upstream to quickly write something that both serves its intended purpose, and also is a subtle security vulnerability, is a risky proposition. Given that the code lifted from systemd serves the same purpose and makes it harder for upstream to negligently introduce security problems, using that seems like the wiser choice. As with all things open source, if systemd upstream tomorrow committed code that broke the ability to use systemd-tmpfiles on an openrc system, Gentoo would not be powerless to deal with it. The Gentoo developers could ship a derivative that reverts that bad commit, or fork at the last known good one.

[Naib]

The dev (and apparently also the rest of opentmpfiles' developers) didn't want to support it anymore because he believed that fixing the security issue was too much work (among other things):
(source)
Do you believe that he is being dishonest?
This wasn't said by some random Gentoo dev, it was the former eudev lead:
(source) (source)
Do you believe that he is being dishonest?

The dev team were being dishonest yes.
The original news item was different and had to be recalled
https://archives.gentoo.org/gentoo-dev/ ... f7632e3ed6

That security issue had been around for well over a year and just sat there because the gentoo security team deemed it not as serious as it could have been. for the original news item to mark it for removal due to security concerns alone as is misleading

That doesn't answer the eudev part. Anyway, as for opentmpfiles, bug 751415, had no reply in Gentoo or on the upstream bug tracker. Undisputed vulnerabilities with no response or fix upstream are generally candidates for masking or last-rites/removal. Someone making an error, there being an oversight, or nobody bothering to explain from an opentmpfiles perspective why something is fine is not being dishonest.

you mean this

(Yes, udev on non-systemd systems is in our eyes a dead end, in case you
haven't noticed it yet. I am looking forward to the day when we can drop
that support entirely.)

(I could dig out the specific threat the Pottering made to Gentoo around this time but we all know it)


and quite interesting just under 10 years ago we have this:
https://archives.gentoo.org/gentoo-dev/ ... c1b992f2b0

That's just now. What other systemd-related restrictions/dependancies
will be eventually rammed down the throats of non-users of systemd?
eudev is a "declaration of independance" for non-systemd users.

there you have it, it was warned

[sam_]

To add on to sam_'s remark, while root privilege may be required to install a dangerous opentmpfiles configuration, that does not mean a dangerous file cannot happen on a system that is otherwise free of malicious privileged users. An upstream developer without malicious intent may, through simple negligence, write and ship a tmpfiles.d configuration that, when processed by opentmpfiles, would be a security problem. Regardless of whether the file is dangerous because of malice or negligence, it may well look reasonable enough that it could pass a simple code review, and only be recognized as a problem when audited by someone who is specifically considering all the edge cases that an attacker might try to apply to it. In the general case, a security review must assume that every security property not guaranteed by the program under test will fail in the attacker's favor. In this situation, that would mean that an unprivileged user might have a full Linux shell running concurrent to the opentmpfiles code processing the bad configuration file. With full shell access, the attacker can make any system calls necessary to try to trip opentmpfiles bugs associated with race conditions.

Obtaining a quality code review is famously hard. Shipping a tool that enables upstream to quickly write something that both serves its intended purpose, and also is a subtle security vulnerability, is a risky proposition. Given that the code lifted from systemd serves the same purpose and makes it harder for upstream to negligently introduce security problems, using that seems like the wiser choice. As with all things open source, if systemd upstream tomorrow committed code that broke the ability to use systemd-tmpfiles on an openrc system, Gentoo would not be powerless to deal with it. The Gentoo developers could ship a derivative that reverts that bad commit, or fork at the last known good one.

Precisely to all of the above. Ditto for udev on the latter point.

[szatox]

The first time that opentmpfiles-setup is run, things are fine; but then suppose I replace "foo" with a symlink:

$ rm -r /var/lib/opentmpfiles-exploit-symlink/foo
$ ln -s /etc/passwd /var/lib/opentmpfiles-exploit-symlink/foo

and restart the service...

$ sudo /etc/init.d/opentmpfiles-setup restart * WARNING: you are stopping a boot service
* Setting up tmpfiles.d entries ...
mkdir: cannot create directory ‘/var/lib/opentmpfiles-exploit-symlink/foo’: File exists

The call to chown has followed my symlink, and given me ownership of /etc/passwd

Oh, cool.
Why doesn't it stop processing this entry after FAILING to create directory? I specifically requested it.
What happens if the definition file (config) is modified to change the owner of some system file directly? What if the app user hard links that file instead of symlinking it? You will have a hard time finding out what that file is. What if it is bind-mounted?

a security review must assume that every security property not guaranteed by the program under test will fail in the attacker's favor. In this situation, that would mean that an unprivileged user might have a full Linux shell running concurrent to the opentmpfiles code processing the bad configuration file. With full shell access, the attacker can make any system calls necessary to try to trip opentmpfiles bugs associated with race conditions.

Fair point, security is difficult to get right, but the suggested solution is an attempt to create a technical patch ('procedure') for a social issue ('incompetence').
People who don't understand capabilities and limitations of the tools they're using will always find a way to shoot their foot. You have no way to know in advance what results all your users will want to achieve.
Don't argue with the admin over an unexpected state, just log an error and nope out of there before making the damage worse.

Unrelated, but a similar example:
I never asked python to convert UTF-8 to ASCII when writing to something else than a terminal.
Due to python "helpfully protecting me from possible incompatibilities down the line because some programs I may want to use in the future don't understand unicode" (no shit Sherlock, but it's not your problem), I spent 2 days figuring out why it worked perfectly when testing and crashed immediately when actually used.
Was it my fault for being stupid, or python's authors for deliberately getting in my way? Oh, right, someone assumed what I wanted.
(And the solution was even dumber than the problem)

[NeddySeagoon]

szatox,

Code: Select all

$ sudo ...

If an attacker already has root you have bigger problems than opentmpfiles.

[szatox]

Neddy, I know that.
Which also is a part of why I fail to see how using any sort of tmpfiles actually makes things better: I just have an impression that this effort moves perpendicularly to it's declared goal, increasing overall complexity in the process.

But then, again, I'm constantly amazed by all the obvious ways people find to shoot themselves.

[pingtoo]

It seems from all I've read, that this was just a theoretical problem, ie it might happen in the future

I agree, this one of the over thinking engineer to believe there is a security issue for opentmpfiles on Gentoo

However I accept the argument that the developer of opentmpfiles wish to stop development and therefor adapt systemd-tmpfiles

I was intrigued by this thread, so I follow all links that relevant to this topic and did some thinking. I believe opentmpfiles is sufficient for Gentoo usage.

Here is my reason,

1. opentmpfiles on Gentoo usage is very different from how a systemd managed system. In a systemd managed system the *tmp files/directory* can happen in unpredictable manner because the dependency design.
   In Gentoo, there are only three place
   • sysinit service opentmpfiles-dev
   • boot service opentmpfiles-setup
   • A ebuild call restart service(s) or call tmpfiles directly
   All of three place require execute by root privilege. so if attacker can involve root privilege, the problem is not at opentmpfiles.
   In Gentoo opentmpfiles only check three place for configuration files
   • /usr/lib/tmpfiles.d
   • /run/tmpfiles.d
   • /etc/tmpfiles.d
   All these three places only root allow to write, All configuration file in those directories own by root and only root allow to change.
2. The openrc/opentmpfile issue CVE-2017-18925 root privilege escalation by symlink attack Really does not apply to Gentoo system.
   because if attacker can modify/create opentmpfiles configuration file as root, than the problem is at system user's privilege management, it is the not the tool.

As mv said earlier, the problem is that:

• upstreams may provide their own tmpfiles configuration which works safely with systemd's implementation, yet doesn't with opentmpfiles
• it's unrealistic and unsustainable for everybody to have to audit both every file from upstream for compatibility and security with opentmpfiles
• if opentmpfiles has footguns that systemd's tmpfiles does not, it's introducing the problems that tmpfiles was trying to solve (avoiding footguns in init scripts by doing things at startup in a standard way)

Also, it being run as root doesn't really absolve anything. This is back to "it's better to make it easier to write a safe init script".

I am sorry, but I disagree with you about this,

upstreams may provide their own tmpfiles configuration which works safely with systemd's implementation, yet doesn't with opentmpfiles

This is the ebuild developer's decision. Should the ebuild developer choose to make it only compatible with systemd's implementation she/he can mark so in USE flag. How ever Gentoo is to give freedom of choose to it's user, it should not be force on to user under security context.

it's unrealistic and unsustainable for everybody to have to audit both every file from upstream for compatibility and security with opentmpfiles

It is not *everyone* it is the ebuild developer I generally hope that Gentoo ebuild developer always aware of security context so they review the configuration requirement from upstreams before it is marked as stable.

if opentmpfiles has footguns that systemd's tmpfiles does not, it's introducing the problems that tmpfiles was trying to solve (avoiding footguns in init scripts by doing things at startup in a standard way)

But this is where we see things different, I believe opentmpfiles does not have the *footguns* you stated under Gentoo's usage, I am not saying the opentmpfiles does not have flaw that stated by the CVE, I am saying the flaw will not happen during the normal Gentoo OpenRC designed usage pattern.