Does Gentoo focus currently more on systemd?

[GDH-gentoo]

So how many packages actually need tmpfiles?

Perhaps it wasn't clear in the other thread. Every package that installs a .conf file in /usr/lib/tmpfiles.d potentially depends on the package that provides systemd-tmpfiles. To know whether it really, really does need it requires analysis and testing... or taking a shortcut a having the software's author tell you. Otherwise, nobody will be able to give you an answer.

The analysis goes like this: take every .conf file, study what it is asking systemd-tmpfiles to do, determine all filesystem changes that would result from not having those files processed (i. e. not running systemd-tmpfiles at boot), and then study the impact of these changes on affected programs... Simple, right?

[K_Brown]

As discussed many times, the future of Gentoo is that it will provide what upstream offers. If the only viable upstream for tmpfiles is systemd, then systemd's tmpfiles will be what Gentoo offers. If some other project offers a tmpfiles processor that is compatible with systemd's tmpfiles, then that other project can also be offered as a provider for virtual/tmpfiles. As it stands, the last release of opentmpfiles is no longer acceptable, so it was removed. If someone were to fix it (which, by some accounts, would be a nearly complete rewrite), it could come back.

Why is systemd's compatibility mandatory?
If the gentoo user is choosing to avoid systemd because of any reason, any systemd mandatory compatibility is an issue. Specially with flawed insecure designs like systemd's tmpfiles.

hadened-tmpfiles is deliberately not compatible with systemd-tmpfiles because of bad security design, It's a not fully compatible replacement.
I can't know how many are using it, but I have not received issue reports for the last two years.
Would you be willing to offer hardened-tmpfiles as a provider for virtual/tmpfiles after near two years of having zero issues reported on without-systemd overlay?

[K_Brown]

I'm only somewhat surprised that it is still possible to not use systemd, but I wonder how long that will remain true.

two years and counting...

[K_Brown]

That depends entirely on how long the programs you want to update continue to work without it. I expect that in most cases, Gentoo maintainers will not have the resources to routinely patch out hard dependencies on systemd, so the question devolves to which upstream projects are committed to working on a systemd-free system versus which ones will rush to embrace every systemd feature as it comes out.

After two years of public availability of without-systemd overlay, I can answer most upstream projects didn't care about systemd other than providing unit files when needed.
I can assure most upstream projects are not beaking at all on a systemd-free system.

[K_Brown]

Does Gentoo focus currently more on systemd?

Gentoo does not focus at all. Gentoo follows $UPSTREAM.

So you should be aware there's more UPSTREAM out there. Not only Systemd.

Code: Select all

		!systemd? (
			|| (
				sys-apps/hardenedtmpfiles
				sys-apps/opentmpfiles
				sys-apps/systemd-utils[tmpfiles]
				sys-apps/tmpfilesd
			)
		)

[K_Brown]

I keep adding the udev USE flag back into packages, so they build on my udev free main desktop.
I suspect that such patches would not be very welcome, so I don't file bugs and/or pull requests.

udev-free containers based on Gentoo) are completely desirable
udev-free containers built with crossdev for smallest size with fewest dependencies i something only Gentoo can acomplish

So, any use flag allowing for reducing dependencies is always greatly appreciated.

[K_Brown]

Gentoo offers as much choice as its active maintainers can volunteer the time to provide. If that is not enough choice for you, join in and offer more, or get patches submitted upstream to create new choices for Gentoo to offer you.

So why don't you stop complaining about being so few and better start accepting contributions from others willing to help?

We have had multiple people wishing for a resurrection of opentmpfiles for a while. Interestingly, your complaint here is yet more evidence you didn't bother to read before posting, because lumaro posted to announce maintenance of opentmpfiles and eudev. I responded to that post questioning the viability of the resurrection, but I must at least give credit that lumaro is attempting to maintain a resurrected opentmpfiles. Have you read that post? Is lumaro's project insufficient for your needs?

Are you still waiting for opentmpfiles resurrection?
https://github.com/KenjiBrown/hardenedt ... /tag/0.5.3
https://github.com/juur/tmpfilesd

[K_Brown]

I think @ndk point is that he expect /etc/tmpfiles.d be root writable only, in order to deploy a exploit for a non-root user, this non-root user must gain root privilege to write in to /etc/tmpfiles.d, but since the user can gain root privilege, what is the point of securing the tmpfiles.d provider? I do think if someone have root privilege to deploy something configuration to be executed by even system-tempfile, the system-tempfile will also suffer from same problem.

because tmpfiles allows the root user to (inadvertently) place a file in /etc/tmpfiles.d with a policy for weakening any directory on the system.

tmpfiles allows the root user to (inadvertently) place a file in /etc/tmpfiles.d with:

Code: Select all

b+    /dev/sda         0660 k_brown disk -           8:0

what could go wong?

[Zucca]

Since you dug this topic up let's talk about this again with today's perspective.

If the gentoo user is choosing to avoid systemd because of any reason, any systemd mandatory compatibility is an issue. Specially with flawed insecure designs like systemd's tmpfiles.

hadened-tmpfiles is deliberately not compatible with systemd-tmpfiles because of bad security design, It's a not fully compatible replacement.

I'd try it but If I need to manually edit many tmpfiles config files, I'll pass.
But what's the flawed design part you talk about? Is it still here today?
I've been happily living with systemd-utils. Those utils are separate from systemd (the init system), so I haven't bothered to even try to change. Same appllies to udev (also comes from systemd-utils). I used eudev at some point, but my custom udev rules failed with eudev and it was impossible for me to get working with eudev.
Personally I'm fine using systemd-utils, but if there's a serious security hole somewhere there and maintainers aren't willing to fix it or I cannot simply avoid it... I start to look for alternatives.

[pingtoo]

I think @ndk point is that he expect /etc/tmpfiles.d be root writable only, in order to deploy a exploit for a non-root user, this non-root user must gain root privilege to write in to /etc/tmpfiles.d, but since the user can gain root privilege, what is the point of securing the tmpfiles.d provider? I do think if someone have root privilege to deploy something configuration to be executed by even system-tempfile, the system-tempfile will also suffer from same problem.

because tmpfiles allows the root user to (inadvertently) place a file in /etc/tmpfiles.d with a policy for weakening any directory on the system.

tmpfiles allows the root user to (inadvertently) place a file in /etc/tmpfiles.d with:

Code: Select all

b+    /dev/sda         0660 k_brown disk -           8:0

what could go wong?

I failed understand your point.

If a root user continue make mistake (inadvertently) there is nothing can help.

And what is that "tmpfiles" in the sentence "because tmpfiles allows the root user ..." refer to? A command? package name? something else?

[NeddySeagoon]

K_Brown,

I use openrc-0.17 which predates opentmpfiles being split out.
Static /dev, no udev ,,, separate /usr and /var, all in LVM on NVMe ...
What could possibly go wrong :)

My udev patched ebuilds are on github in my gentoo-static overlay.

[K_Brown]

Since you dug this topic up let's talk about this again with today's perspective.

If the gentoo user is choosing to avoid systemd because of any reason, any systemd mandatory compatibility is an issue. Specially with flawed insecure designs like systemd's tmpfiles.

hadened-tmpfiles is deliberately not compatible with systemd-tmpfiles because of bad security design, It's a not fully compatible replacement.

I'd try it but If I need to manually edit many tmpfiles config files, I'll pass.

You don't need to manually edit many tmpfiles, hopefully none. Only the ones doing risky things could be broken, but in such case, it should be worh looking into it to understand why such specific tmpfiles is generating insecure conditions.

But what's the flawed design part you talk about? Is it still here today?

It's still there. It allows for any package maintainer to to set wrong rules potentially damaging the system or creating unnecessary risk.
I am not thinking on package maintainers sabotaging on purpose, but trojaned pipelines have already happened in the past and wull continue happening. Nothing prevents an undetected trojaned pipeline to use tmpfiles' power to weaken the security or even provoke big damage on the system. Some checks on haredenedtmpfiles so prevent some kinds of security weakening or unwanted deletion, without breaking existing tmpfiles entries that only mess with their own files and paths.

I've been happily living with systemd-utils. Those utils are separate from systemd (the init system), so I haven't bothered to even try to change. Same appllies to udev (also comes from systemd-utils). I used eudev at some point, but my custom udev rules failed with eudev and it was impossible for me to get working with eudev.

You have been happily living in a comfort zone. I don't care about your live neither about your particular comfort cases.
What I care about is for the users who are a little more security concious and «better fail than corrupting», to have a choice. The choice to use a different tmpfiles other than systemd's.
Choice is already there, two years in UPSTREAM. There's no reason to keep refusing it, regardless of any comfort use cases where people are happily living in Candyland.

Personally I'm fine using systemd-utils, but if there's a serious security hole somewhere there and maintainers aren't willing to fix it or I cannot simply avoid it... I start to look for alternatives.

[K_Brown]

I failed understand your point.

It's not that complicated. systemd's tmpfiles allows to easily shoot yourself in the foot while other tmpfiles replacement provides means to prevent it.

If a root user continue make mistake (inadvertently) there is nothing can help.

Does sys-apps/coreutils allow the root user to rm -rf / anymore?

And what is that "tmpfiles" in the sentence "because tmpfiles allows the root user ..." refer to? A command? package name? something else?

https://www.man7.org/linux/man-pages/ma ... s.d.5.html
Another example:

Code: Select all

e     /var/lib                   0755 nobody nobody 0 -

[K_Brown]

I use openrc-0.17 which predates opentmpfiles being split out.
Static /dev, no udev ,,, separate /usr and /var, all in LVM on NVMe ...
What could possibly go wrong

I also use use static-dev. I use it on tens of vservers without udev, without eudev, without needing any overlay. Gentoo just allows me to do it. Gentoo provides us with that choice. It does without beaking anybody else's default installations.
However, in order to use a different tmpfiles (other than systemd's) I had to put an overlay on Github (just as you did) with different choices other than systemd's and a package.mask to prevent systemd-utils from inadvertently installing (as it was about to happen a couple of times when virtual/tmpfiles version bumps).
I wish it was as easy as emerge --unmerge systemd-utils but it's not. It happens that virtual/tmpfiles is dependency for the system profile, just as virtual/dev-manager is.

The difference is choice. virtual/dev-manager allows me to choose sys-fs/static-dev. virtual/tmpfiles gives me no choice.

[pingtoo]

I failed understand your point.

It's not that complicated. systemd's tmpfiles allows to easily shoot yourself in the foot while there are means to prevent it.

If a root user continue make mistake (inadvertently) there is nothing can help.

Does sys-apps/coreutils allow the root user to rm -rf / anymore?

And what is that "tmpfiles" in the sentence "because tmpfiles allows the root user ..." refer to? A command? package name? something else?

https://www.man7.org/linux/man-pages/ma ... s.d.5.html
Another example:

Code: Select all

e     /var/lib                   0755 nobody nobody 0 -

Thank you for the information.

I did not know sys-app/coreutils have that protection.

But my guess busybox rm -rf / still work.

Just like there is no editor can be conditioned not allow root user write incorrect content in to a file.

If I remember correctly the "tmpfiles" by default located in protected directories, non-privileged user should not have permission to create content in those directories. it was my original argument for that CVE about the condition use should not occur in Gentoo at that time, because "tmpfile" under openrc does not execute all the time. It was only used at start of system or emerge install package which require privileged user. so the CVE described scenario will not occur. However understand systemd it does happen more frequent. so I did not argument further.

[GDH-gentoo]

it was my original argument for that CVE about the condition use should not occur in Gentoo at that time, because "tmpfile" under openrc does not execute all the time.

systemd-tmpfiles never executes "all the time". Not even on systemd-based Gentoo.

Also systemd-tmpfiles --clean runs daily on both OpenRC-based and systemd-based Gentoo with a standard setup. Unless you are using OpenRC and don't have a cron daemon installed.

I don't expect there is really any difference in when exactly systemd-tmpfiles runs in each case.

[pingtoo]

it was my original argument for that CVE about the condition use should not occur in Gentoo at that time, because "tmpfile" under openrc does not execute all the time.

systemd-tmpfiles never executes "all the time". Not even on systemd-based Gentoo.

Also systemd-tmpfiles --clean runs daily on both OpenRC-based and systemd-based Gentoo with a standard setup. Unless you are using OpenRC and don't have a cron daemon installed.

I don't expect there is really any difference in when exactly systemd-tmpfiles runs in each case.

Thank you for the information.

Then I was not into using systemd so did not have much experience with how systemd work. I just remember I saw some kind of service name resemble tmpfiles so I assume it is something system will perform all the time.

I don't know if the daily run on OpenRC exist when I making the argument then. I am pretty sure then on my openrc system I don't have daily job that does systemd-tmpfiles. Or at least I did not see it in cron log.

I do agree if the systemd-tmpfiles function executed in a consistent manner then that CVE be more easier to explore. However I always believe system security are multiple layers therefor it should not be expected from the single utility to ensure it is not exploitable by someone with knowledge.

[GDH-gentoo]

I am pretty sure then on my openrc system I don't have daily job that does systemd-tmpfiles. Or at least I did not see it in cron log.

sys-apps/systemd-utils with the tmpfiles USE flag set installs /etc/cron.daily/systemd-tmpfiles-clean.

[figueroa]

The discussion got me interested. My /tmp shows the following permissions:

Code: Select all

drwxrwxrwt 390 root     root        36864 Mar 31 14:56 ./

Is that what it should be? Anybody can write to /tmp as it is. I am using up-to-date sys-apps/systemd-utils.

[Hu]

Yes, sticky (t), and read-write-search (rwx) for user, group, other is standard for /tmp.

[K_Brown]

The discussion got me interested. My /tmp shows the following permissions:

Code: Select all

drwxrwxrwt 390 root     root        36864 Mar 31 14:56 ./

Is that what it should be? Anybody can write to /tmp as it is. I am using up-to-date sys-apps/systemd-utils.

This one might be difficult to detect until it's doing harm::

Code: Select all

D     /var/tmp/mistyped/other-process          0750 myuser mygroup 86400

A tmpfiles entry mistakenly changing ownership to a mistyped directory belonging to other process.

[Hu]

To be sure I understand, your argument against tmpfiles is that someone with permission to write a tmpfiles entry might do a bad job of it, and that makes tmpfiles bad? Yet someone with permission to write an init script can write it poorly and introduce a race condition or other security problem, and that is acceptable, because the author is misusing bash, not misusing tmpfiles?

[K_Brown]

To be sure I understand, your argument against tmpfiles is that someone with permission to write a tmpfiles entry might do a bad job of it, and that makes tmpfiles bad? Yet someone with permission to write an init script can write it poorly and introduce a race condition or other security problem, and that is acceptable, because the author is misusing bash, not misusing tmpfiles?

Not exaxtly.
The tmpfiles specification can be exploited to perform unwanted changes on the filesystem; some of them harmful.
Other tmpfiles implementations (like hardenedtmpfiles) can prevent some of those unwanted changes while being compatible enough not to break a Gentoo installation, unless some single package is doing something wrong (or worth analyzing deeper).

My first complain is those alternative tmpfiles implementations have been rejected for the last two years with no other explaination than comfort zone particular cases.

My second complain is user choice. The same choice we have been grateful to Gentoo all this years.

The virtual/tmpfiles ebuild on without-systemd overlay restores lost user's choice without any major maintenance requirement.
Most Gentoo users will stay comfortable with sys-apps/systemd-utils[tmpfiles] without needing to change anything, but those who (knowingly) want alternatives will be able to choose and change.
https://github.com/KenjiBrown/without-s ... -r6.ebuild

I waited two years to make sure enough users of without-systemd overlay have no noticeable issues while using different alternatives to systemd's tmpfiles.
While I can't know how many people are using the overlay (other than ocasional mentions on some telegram channels), most issue reports I have received are about package.mask rejections every time Gentoo's virtual/tmpfiles bumped version. The only non-issue issue was the inclusion of tmpfilesd as a third choice.