Fedora and pkexec

Posted Feb 16, 2022 14:42 UTC (Wed) by CodingVoid (guest, #156336)
In reply to: Fedora and pkexec by mjg59
Parent article: Fedora and pkexec

I see your point.
I guess the root of the problem resides in the fact, that one needs to communicate with a daemon/priviledged process in the first case. First thing I do on my personal system, after installing my distribution of choice is disable/mask 80% of all systemd services/timers/sockets (of course I check whether I need the services features before disabling).
I guess it's all personal preference and all but I am more into using libraries instead of having 10 socket connections to some priviledged daemons, which do the stuff for me.

Fedora and pkexec

Posted Feb 16, 2022 17:25 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (3 responses)

> I guess it's all personal preference and all but I am more into using libraries instead of having 10 socket connections to some priviledged daemons, which do the stuff for me.

As someone who would like their program to be more robust, not having to load in arbitrary code into my process space makes me feel a lot better. Loading PAM or NSS plugins to do things on my behalf sounds a lot worse when they can take my process down instead of giving me back an error that I can explicitly handle. Some PAM plugins don't even work as intended because their configuration files aren't world-readable, so a separate process is just a better way with them.

Additionally, if one is running something like WINE or other architectures (QEMU or whatever), there can be more sharing of permissions instead of having to figure out how to make them load compatible plugins/configurations as well.

There are tradeoffs, but given that `dlopen` can just run arbitrary code, I don't like it for "must not fail" processes at all. Sure, you can also link to these libraries at build time, but "loading libraries" is usually done in languages with…sad package management.

Fedora and pkexec

Posted Feb 18, 2022 11:01 UTC (Fri) by CodingVoid (guest, #156336) [Link] (2 responses)

> As someone who would like their program to be more robust, not having to load in arbitrary code into my process space makes me feel a lot better. Loading PAM or NSS plugins to do things on my behalf sounds a lot worse when they can take my process down instead of giving me back an error that I can explicitly handle. Some PAM plugins don't even work as intended because their configuration files aren't world-readable, so a separate process is just a better way with them.
But then the problem resides in the libraries itself. reading that it sounds like polkit is just 'patch' for bad written libraries.

> Additionally, if one is running something like WINE or other architectures (QEMU or whatever), there can be more sharing of permissions instead of having to figure out how to make them load compatible plugins/configurations as well.
Could you be more specific? Who shares permissions with whom in that example?

> Sure, you can also link to these libraries at build time, but "loading libraries" is usually done in languages with…sad package management.
I don't really follow. Could you explain?

Fedora and pkexec

Posted Feb 18, 2022 11:29 UTC (Fri) by farnz (subscriber, #17727) [Link]

As an example of where the local process over UNIX Domain Sockets approach is strictly better than the library approach: there are ways to authenticate via a remote RADIUS server where I use machine secrets to establish an encrypted session with the remote server, and then send the user's credentials over that tunnel. If you do this via a library, then all processes on the system that need to authenticate need to be able to read the machine secrets, which implies that the machine secrets are world-readable. If, instead, you use a local process over a socket, that process can run as root, and the machine secrets need only be readable by root.

Fedora and pkexec

Posted Feb 18, 2022 18:08 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

> But then the problem resides in the libraries itself. reading that it sounds like polkit is just 'patch' for bad written libraries.

Badly written libraries are everywhere. Even so, it misses the case where the process doing the check needs higher permissions to be able to read some configuration file. Running every PAM-using process as `suid` on the off-chance a configuration file is not world-readable sounds like a terrible solution.

> Could you be more specific? Who shares permissions with whom in that example?

Instead of having to have a way for a WINE process to load a PAM module to be able to check a password, you can implement "talk to a socket" without having to port some (typically very-Unixy) code over to Windows-isms. Rather, you just implement "list users" and "authenticate this user" APIs in terms of socket communication which sounds…way nicer IMO.

> I don't really follow. Could you explain?

C and C++ have terrible package management. How to use package $x differs based on the build system you use as well as the project you would like to consume. Alas, solving this is *hard* because C and C++ developers have gotten accustomed to all the power that "make my own command line" offers.

Now, any C or C++-specific way that goes down a similar path as Python's PyPI, Rust's cargo, or Node's NPM will have the issues of those ecosystems: that using any interface that is not the language under consideration is extremely hard. Sure `pip install h5py` works, but if I have another library that wants to use HDF5's C interfaces, I'm SOL because `pip` has no way for such a thing to be offered or expressed as a strict enough dependency that ABI considerations require. NumPy is the only one that does it well and that's because it is *only* a Python package, not another package being stuffed into the Python world.