view the rest of the comments
Linux
Welcome to c/linux!
Welcome to our thriving Linux community! Whether you're a seasoned Linux enthusiast or just starting your journey, we're excited to have you here. Explore, learn, and collaborate with like-minded individuals who share a passion for open-source software and the endless possibilities it offers. Together, let's dive into the world of Linux and embrace the power of freedom, customization, and innovation. Enjoy your stay and feel free to join the vibrant discussions that await you!
Rules:
-
Stay on topic: Posts and discussions should be related to Linux, open source software, and related technologies.
-
Be respectful: Treat fellow community members with respect and courtesy.
-
Quality over quantity: Share informative and thought-provoking content.
-
No spam or self-promotion: Avoid excessive self-promotion or spamming.
-
No NSFW adult content
-
Follow general lemmy guidelines.
Lots of rambling in this comment. Solution below the heading.
From a security perspective of limiting privileges it doesn't quite work. If they can run
apt installthen they can install a malicious hand crafted package, that has an install script that runs with root privileges, or enables a systemd service or so on.From a preventing users from doing stupid stuff, it mostly works. Of course, there are still ways it can break, like when Linus Tech Tips typed in
yes, do as I saywhen apt had a bug and refused to continue because it suspected that something would break and then Linus did it anyways...But it will mostly work.
Firstly, I want to mention that flatpak does not need root and can work without root. So if the goal is to have users be able to install apps from the app store, you could remove non flatpak apps from the GUI, and then they would be able freely install and remove apps from the GUI app store. They can also use the flatpak cli, but it's more difficult to use.
Secondly, I agree with the other commenter. It's probably way easier to make a backup, or use syncthing, and just give them root if that getting them apt packages the goal. If you do something like automatic btrfs snapshots (which Linux Mint has support for), it mostly gets you to the goal of "I don't want a privileged user to break their system", since it is easy to walk them through booting into an older snapshot over the phone.
If your goal is actual management of
aptprograms, then the specific problem you are encountering is that there are two methods of authorizing to root, and you have configured only one of them so far. There issudo, which governs cli programs, but there is alsopolkit, which governs GUI programs. Polkit has a cli command that has a similar feature to sudo,pkexec, which you can use for testing configuration of polkit.Since it looks like you got sudo working I won't waste time on that. Here is a nice intro from Red Hat:
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/desktop_migration_and_administration_guide/policykit
Hmm doesn't have what I want. (I am figuring out as I go).
Okay it looks like the GUI stuff is powered by packagekit, which is an actual daemon: https://en.wikipedia.org/wiki/PackageKit (I thought it was just a library/interface), that runs as root. You can use the
pkgclito interact with it from the command line, and it still uses polkit.Okay here is the relevant policy file: https://github.com/PackageKit/PackageKit/blob/main/policy/org.freedesktop.packagekit.policy.in
Solution Here
Polkit rules are written in javascript, so you would want a rule that's something like:
And put this in
/etc/polkit-1/rules.d/10-enable-rootless-packagekit.rulesThis does read from the local unix groups, not active directory groups, meaning you have to ensure it's present there, and also have the exact name, which is not used in the sudoers file example above.
if you run
getent group, then it should be exact name of the group in that list.Thank you! I will try that and update this post if it works.