One is written in shell, the other is written in c.(no problems here)
One is not part of systemd, the other is.
How are they identical.

I use this on my raspi server, works fine.

Gentoo really became a systemd distro, further restricting choice by the day.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 2023-09-17 at 08:26 +0300, Alexe Stefan wrote:

One is written in shell, the other is written in c.(no problems here)
One is not part of systemd, the other is.
How are they identical.

I use this on my raspi server, works fine.

Gentoo really became a systemd distro, further restricting choice by
the day.

http://www.islinuxaboutchoice.com/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 9/17/23, David Seifert <soap@gentoo.org> wrote:

On Sun, 2023-09-17 at 08:26 +0300, Alexe Stefan wrote:

One is written in shell, the other is written in c.(no problems here)
One is not part of systemd, the other is.
How are they identical.

I use this on my raspi server, works fine.

Gentoo really became a systemd distro, further restricting choice by
the day.

http://www.islinuxaboutchoice.com/

That mail is about fedora, the furthest you can go away from choice on linux. However, that page talks about fedora as if all of linux is fedora.
Gentoo is not fedora... yet.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Arsen Arsenović <arsen@gentoo.org> writes:

[snip]

How are they identical.

The last rites message does not say that opentmpfiles and
systemd-tmpfiles are identical. That'd do a disservice to the actually complete, unmaintained, and (currently) non-CVE-affected implementation

^^ C-h C-h... typo'd.

in systemd.

[snip]
--
Arsen Arsenović

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iOcEARYKAI8WIQT+4rPRE/wAoxYtYGFSwpQwHqLEkwUCZQbgGV8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0RkVF MkIzRDExM0ZDMDBBMzE2MkQ2MDYxNTJDMjk0MzAxRUEyQzQ5MxEcYXJzZW5AZ2Vu dG9vLm9yZwAKCRBSwpQwHqLEk2sJAQDM061AcOP1VK0JEioNNFmRb9pYo2W2WYTE aK4Df+ZtJQEAi9MRyKMSrOelc3XUOECqd90t7IIV7GWHmchWT1V3ego=V5ZO
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-09-17 08:26:50, Alexe Stefan wrote:

One is written in shell, the other is written in c.(no problems here)
One is not part of systemd, the other is.
How are they identical.

The big picture is that the tmpfiles.d specification is impossible to
implement securely on a POSIX system. The systemd devs wrote a
specification to appease the people who complained, but that doesn't
change the fact that the spec is fundamentally flawed unless you
happen to be implementing it on a new linux system. (The authors
didn't know this at the time, so it was not a dirty trick.)

As a result, opentmpfiles never should have tried to implement it, but
its authors didn't know about those problems either. And while
implementing tmpfiles in C has certain unavoidable race conditions,
hooooooooo boy is the shell version swiss cheese. There's no safe way
to run chown and chmod (the shell commands) as root in a directory you
don't control, and that's a big part of what opentmpfiles does. The
exploits for the shell version are kindergaren stuff.

The systemd folks put in a lot of work to make sure that the race
window is a small as possible in systemd-tmpfiles. And on linux with
kernel hardening, you're safe. Given that no one is working towards
replacing tmpfiles completely, here's where that leaves us.

We have the systemd utility that is as secure as possible, and
opentmpfiles that tries to mimic it but is unmaintained and much less
secure. At best, the insecure version could be rewritten in C to make
it.... basically identical to the systemd version? Which has no real
problems aside from the fact that it has systemd in the name. And no
one is volunteering to do that rewrite in the first place. Newer linux
systems are well supported by systemd-tmpfiles, and that's the only
place tmpfiles is safe to begin with.

It sucks that we're all stuck with tmpfiles now but you're only
shooting yourself in the foot if you insist on using the worst
possible implementation of it.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Alexe Stefan <stefanalexe48@gmail.com> writes:

One is written in shell, the other is written in c.(no problems here)

Not that implementation language matters.

One is not part of systemd, the other is.

Both work fine without systemd, but the systemd implementation also
happens not to be unmaintained and happens to be more complete.

How are they identical.

The last rites message does not say that opentmpfiles and
systemd-tmpfiles are identical. That'd do a disservice to the actually complete, unmaintained, and (currently) non-CVE-affected implementation
in systemd.

I use this on my raspi server, works fine.

'WOMM' is a fairly terrible measure.

Gentoo really became a systemd distro, further restricting choice by
the day.

[ignoring this nonsensical statement, notice put here for clarity]


Gentoo devs aren't obliged to maintain software you like to use. systemd-utils[tmpfiles] works on all Gentoo systems, including
non-systemd ones. Until that changes (which is unlikely), I doubt there
will be much interest in maintaining a fork from inside Gentoo.

Please take up opentmpfiles maintenance. You have https://archives.gentoo.org/gentoo-dev/message/689954cc7fd55402dc4c82aa0ac70efb to address, and probably some other issues. See https://github.com/OpenRC/opentmpfiles/issues/19 for context.

The message above implies that a rewrite in C is necessary.

This should be rather easy. The systemd implementation is only ~4k LoC (excluding shared code), so I imagine that a complete reimplementation
should be far less than 10k. Since this is fairly elementary stuff, it
should be possible to finish in a weekends time.

Submit a PR to re-add opentmpfiles after you're done.

Looking forward to reviewing your contributions upstream. Have a lovely
day :-)
--
Arsen Arsenović

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iOcEARYKAI8WIQT+4rPRE/wAoxYtYGFSwpQwHqLEkwUCZQbfq18UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0RkVF MkIzRDExM0ZDMDBBMzE2MkQ2MDYxNTJDMjk0MzAxRUEyQzQ5MxEcYXJzZW5AZ2Vu dG9vLm9yZwAKCRBSwpQwHqLEk/hAAP9+DrXAWK+16z/+ncMTO3aro2/5OGzk92dH n58QE2xFjAD+KhkGiyCNs4Fe+G23G0ZLb1+P9IT7wx1wrLdSVKvuiA8=w1T+
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 17 Sep 2023 12:58:00 +0200
Arsen Arsenović <arsen@gentoo.org> wrote:

Alexe Stefan <stefanalexe48@gmail.com> writes:

One is written in shell, the other is written in c.(no problems
here)

Not that implementation language matters.

One is not part of systemd, the other is.

Both work fine without systemd, but the systemd implementation also
happens not to be unmaintained and happens to be more complete.

Here are some other implementations I have found, but I am not sure if
they are drop-in replacements or not.

https://github.com/eweOS/pawprint
https://github.com/juur/tmpfilesd

How are they identical.

The last rites message does not say that opentmpfiles and
systemd-tmpfiles are identical. That'd do a disservice to the
actually complete, unmaintained, and (currently) non-CVE-affected implementation in systemd.

I use this on my raspi server, works fine.

'WOMM' is a fairly terrible measure.

Gentoo really became a systemd distro, further restricting choice by
the day.

[ignoring this nonsensical statement, notice put here for clarity]

Gentoo devs aren't obliged to maintain software you like to use. systemd-utils[tmpfiles] works on all Gentoo systems, including
non-systemd ones. Until that changes (which is unlikely), I doubt
there will be much interest in maintaining a fork from inside Gentoo.

Please take up opentmpfiles maintenance. You have https://archives.gentoo.org/gentoo-dev/message/689954cc7fd55402dc4c82aa0ac70efb
to address, and probably some other issues. See https://github.com/OpenRC/opentmpfiles/issues/19 for context.

The message above implies that a rewrite in C is necessary.

This should be rather easy. The systemd implementation is only ~4k
LoC (excluding shared code), so I imagine that a complete
reimplementation should be far less than 10k. Since this is fairly elementary stuff, it should be possible to finish in a weekends time.

Submit a PR to re-add opentmpfiles after you're done.

Looking forward to reviewing your contributions upstream. Have a
lovely day :-)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Sonntag, 17. September 2023, 13:53:45 CEST schrieb Michael Orlitzky:

On 2023-09-17 08:26:50, Alexe Stefan wrote:

[...]

I just want to say how amazed I am that you (and Arsen, too) still have the patience to try and explain the realities of the situation like this, especially after the eudev thread.

Greetings
--
Marc Joliet
--
"People who think they know everything really annoy those of us who know we don't" - Bjarne Stroustrup

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQS2YUPDQn1ADQEoj0uXgvYOs+E2oAUCZQb//gAKCRCXgvYOs+E2 oJdeAQCfQHl4AuZhia+eI4r2M3wMQMlQzmIos3zk5XzQTeYmdQD/Yqng5pq0EnX1 kYTPwGfttStIrPINfIf5Ze5qxrWg2QI=
=ViX9
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-09-17 15:32:46, Marc Joliet wrote:

I just want to say how amazed I am that you (and Arsen, too) still have the patience to try and explain the realities of the situation like this, especially after the eudev thread.

I'm a founding member of the systemd haters club so I'm sympathetic,
but in this case there are only a few realistic paths forward and none
of them involve opentmpfiles.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 9/17/23, orbea <orbea@riseup.net> wrote:

On Sun, 17 Sep 2023 12:58:00 +0200
Arsen Arsenović <arsen@gentoo.org> wrote:

Alexe Stefan <stefanalexe48@gmail.com> writes:

One is written in shell, the other is written in c.(no problems
here)

Not that implementation language matters.

One is not part of systemd, the other is.

Both work fine without systemd, but the systemd implementation also
happens not to be unmaintained and happens to be more complete.

Here are some other implementations I have found, but I am not sure if
they are drop-in replacements or not.

https://github.com/eweOS/pawprint
https://github.com/juur/tmpfilesd

How are they identical.

The last rites message does not say that opentmpfiles and
systemd-tmpfiles are identical. That'd do a disservice to the
actually complete, unmaintained, and (currently) non-CVE-affected
implementation in systemd.

I use this on my raspi server, works fine.

'WOMM' is a fairly terrible measure.

Gentoo really became a systemd distro, further restricting choice by
the day.

[ignoring this nonsensical statement, notice put here for clarity]


Gentoo devs aren't obliged to maintain software you like to use.
systemd-utils[tmpfiles] works on all Gentoo systems, including
non-systemd ones. Until that changes (which is unlikely), I doubt
there will be much interest in maintaining a fork from inside Gentoo.

Please take up opentmpfiles maintenance. You have
https://archives.gentoo.org/gentoo-dev/message/689954cc7fd55402dc4c82aa0ac70efb
to address, and probably some other issues. See
https://github.com/OpenRC/opentmpfiles/issues/19 for context.

The message above implies that a rewrite in C is necessary.

This should be rather easy. The systemd implementation is only ~4k
LoC (excluding shared code), so I imagine that a complete
reimplementation should be far less than 10k. Since this is fairly
elementary stuff, it should be possible to finish in a weekends time.

Submit a PR to re-add opentmpfiles after you're done.

Looking forward to reviewing your contributions upstream. Have a
lovely day :-)

There are 2 open pr's on the opentmpfiles github. One removes the
security vulnerability, but is non-compliant with the spec, the other
is (at least is a start of) a rewrite in c.

As a result, opentmpfiles never should have tried to implement it, but
its authors didn't know about those problems either. And while
implementing tmpfiles in C has certain unavoidable race conditions, >hooooooooo boy is the shell version swiss cheese. There's no safe way
to run chown and chmod (the shell commands) as root in a directory you
don't control, and that's a big part of what opentmpfiles does. The
exploits for the shell version are kindergaren stuff.

Is it really so easy to exploit it?
How would you do that?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Sonntag, 17. September 2023, 15:32:46 CEST schrieb Marc Joliet:

Am Sonntag, 17. September 2023, 13:53:45 CEST schrieb Michael Orlitzky:

On 2023-09-17 08:26:50, Alexe Stefan wrote:

[...]

I just want to say how amazed I am that you (and Arsen, too) still have the patience to try and explain the realities of the situation like this, especially after the eudev thread.

(Just to be clear: I mean this as a compliment!)

--
Marc Joliet
--
"People who think they know everything really annoy those of us who know we don't" - Bjarne Stroustrup

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQS2YUPDQn1ADQEoj0uXgvYOs+E2oAUCZQczCwAKCRCXgvYOs+E2 oPUrAQDrlWM53CxKi2eKRD1BkKT36HHD+sq/+R4aerFa87fafAD+MzRncpwdCLxS q7Heg5qc9hXYvr/uFmYg98FOQD0FOgU=
=YrW+
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 17 Sep 2023 13:25:20 -0400
Michael Orlitzky <mjo@gentoo.org> wrote:

On 2023-09-17 15:32:46, Marc Joliet wrote:

I just want to say how amazed I am that you (and Arsen, too) still
have the patience to try and explain the realities of the situation
like this, especially after the eudev thread.

I'm a founding member of the systemd haters club so I'm sympathetic,
but in this case there are only a few realistic paths forward and none
of them involve opentmpfiles.

I'll say I agree too, I would like to stop using systemd-tmpfiles, but opentmpfiles is not a viable choice.

Given this commit.

https://github.com/OpenRC/opentmpfiles/commit/f33d0ea74bb0ab8bdf53e3df499323a828b3b1df

And this comment.

https://github.com/OpenRC/opentmpfiles/issues/19#issuecomment-877663396

At this point opentmpfiles seems actually dead and unmaintained, it
also seems doubtful that will change in the foreseeable future. Its
better to look into alternatives instead.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-09-17 20:28:49, Alexe Stefan wrote:

There are 2 open pr's on the opentmpfiles github. One removes the
security vulnerability, but is non-compliant with the spec, the other
is (at least is a start of) a rewrite in c.

The PR is still vulnerable. These checks,

_chown() {
local path=$2 uid=$1
if ! owned_by_root "${path}" ; then
...

are insufficient to fix the vulnerability, because it's the parent
path(s) that are the problem. If any parent path is writable by a
non-root user, that non-root user can swap it out from under you,
even if the thing you're operating on is root:root.

AFAIK it's impossible to fix that in shell. In C, you can do a little
openat() dance ensuring that each component of your path is safe from
the root upwards -- that's why one of the suggestions is to rewrite opentmpfiles in C.

As a result, opentmpfiles never should have tried to implement it, but
its authors didn't know about those problems either. And while
implementing tmpfiles in C has certain unavoidable race conditions, >hooooooooo boy is the shell version swiss cheese. There's no safe way
to run chown and chmod (the shell commands) as root in a directory you >don't control, and that's a big part of what opentmpfiles does. The >exploits for the shell version are kindergaren stuff.

Is it really so easy to exploit it?
How would you do that?

The daemon runs "ln" or "ln -s", basically at its leisure, and
waits for opentmpfiles to run again.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)