I feel obligated to give some context about why they are excited, since the article seems to be targeting people who understand. Specifically, this part:
"blue screen of the death" or "Oops"... except that it's just an error! It doesn't take your whole system away with it, only the particular operations that was going on.
There are two theoretical kernel architectures: Microkernel, and monolithic kernel.
The primary advantage of a monolithic kernel is performance. All modern operating systems a monolithic kernels [1]. The big advantage of a microkernel is security.
With a monolithic kernel, almost everything runs privileged, in the kernel. Hardware interactions, drivers, firewalls, various processes. The big disadvantage of this, is that if any of those components have a bug and crash, it bluescreens.
The best example was the crowdstrike blue screen of death issues: https://en.wikipedia.org/wiki/2024_CrowdStrike-related_IT_outages . Crowdstrike runs at the kernel level (kind of like kernel level anticheat), and it had a bug, causing BSOD's everywhere. Of course, this is a fairly drastic example. Anecdotally, I have noticed in an increase in random BSOD's from people who have kernel level anticheat installed. Of course, the average user never whines and you have to pull this out of them, they just treat this as "normal".
With a microkernel, things are different. Everything is separated out, running as less privileged processes. This has big security implications since, it means that pwning one component of the Linux kernel, wouldn't own the whole kernel. That has been how so many of the recent Linux kernel root exploits have happened, where subsystems, rather than the entire kernel are vulnerable. With a microkernel, the possibility of an exploit in say, the containerization/sandboxing features, wouldn't lead to a root exploit on the host. SImilarly, components like device or filesystem drivers could be put in userspace as well, enabling much better security and isolation.
[1], well, sometimes people try to argue that the difference between a microkernel and a monolithic kernel is about codebase organization, optimizing for development velocity. Windows, and Mac are called "hybrid kernels", because the core kernel code is separated from things like drivers, enabling people to develop them separately. This used to be a bigger deal back in the day, since it enabled faster development for things like peripherals.
But there is no security or correctness benefit, so I consider them a monolithic kernel. In addition to that, "true" monolithic kernels (like Linux) have since innovated. While being open source may not be a big deal to us today, it was an innovation on it's own, that enabled people to include the firmware/drivers in the kernel directly (albeit, sometimes as binary blobs distributed in linux-firmware). In addition to that, there is also dkms for loading out of tree kernel modules, or epbf which enables you to run arbitrary code with ring 0 level privileges... but in such a way that it also doesn't hard crash the system when there is a bug.
Yes, although there have been a few CVE's related to escalating privileges or breaking out of the sandbox. You're going to want to keep those updating and keep on top of those.
There is one concern, in that the nix store (/nix/store) is world readable. It is not world writable, which is good, but there is a problem in that secrets can potentially be copied into the nix store. If you copy a file containing environment variables or the like into the nix store, it could theoretically be found it. This one is on the users of nix to be careful of.
With Nix flakes, the entire git repo that the flake originates from is copied into the nix store. Meaning if you have a nix flake in something that is supposed to be a private repo, or contains tracked sensitive data (untracked files are not copied into the nix store), then it could be found and inspected by other users.
My big concern with multi user in this case is not merely the Nix daemon though, but also Linux itself. Linux has been hit with a LOT of privilege escalation and container escape issues over the past few years, and many of them have been zero day's. Given this, I no longer really have the same level of trust for Linux with regards to multi user isolation, for in cases like these.
Of course, in academic computing, I would probably just do multi user anyways, for simplicity. If you install tracking and monitoring, then you can attach malicious actions to identities. Because every user is registered and operates within the institution, if they break the terms of use for computing equipment, then you can punish them within the institution, or pursue greater legal action.
And then, you also would want to enforce 2FA to help minimize stolen accounts. While that can still be phished via fake login pages that ask for 2FA, it handles most of the things. Isolate the server via firewalls, and then it becomes a small enough target that doesn't have enough value (assuming of course, your research isn't too valuable and worth targeting), and you mostly don't have to worry about it.
Sure, people will root it. But then they'll send you a nicely worded email explaining how they rooted it and how to fix it. Which is what my friend did at my school, on our shared ssh server. Just keep it updated to handle the low hanging fruit.
However, if you are going to give it to untrusted users with unknown or temporary (not within the institution) identities, then things change, and you have to take it a lot more seriously. I no longer have confidence in just Linux's user based isolation.
The first line solution I would go to, is to put users in containers and mount the nix store (and nix daemon) in and out. Something like a docker/podman container or Incus container. Of course, container escapes are still possible. If you are even more concerned about those, then you would want virtual machines. It is still possible to share the nix store between virtual machines, but it is more complicated.
In addition to that, virtual machines have a performance tradeoff (usually 95% or more of the host's performance though), but there might be issues with sharing GPU compute resources among virtual machines, depending on the hardware you are using. Enterprise GPU's usually support it though.
then, when you double click on an exe you downloaded in your file explorer, it will launch and open.
Many of the user friendly Linux distros do this.
Of course there are caveats, in that if you run an installer, it might not show up in your desktop or so on. And any programs that need admin or have heavy drm also won't run.
Debian has a policy of only cherry picking security updates, or critical bugfixes, in order to ensure maximum system stability. In general, they don't do entire program updates or additional features. For the 4 year lifecycle of a Debian release, it will behave the same as it did yesterday.
the physical display output is claimed by something else totally separate.
Yes, and the above solution I laid out is a way to get around that, that potentially dodges the complexity of configuring a truly headless session. It's possible to run two KDE sessions at once, next to eachother, and then simply put one on the main display, with the second being "headless", and not shown.
I started fiddling with the above setup I described, actually installing and testing sunshine. Unfortunately I hit some hiccups. I got sunshine to run, but with no input, and then then it attached to the wrong KDE, even though it was streaming the correct one initially. Now I'm running the same KDE session as a different user (since I was on the same user before), but having pairing issues, but I suspect these are because moonlight is seeing the wrong SSL cert, since the sunshine as a new user generated a new cert.
If you don't have internet, which you may need for some of the fixes mentioned here, you can try tethering, which is where you share a phone's internet with a computer over a wired connection.
There is also this guide, but it is specific for Xorg and Nvidia gpus. But I suspect that if you replace the startx here with startplasma-wayland or dbus-run-session startplasma-wayland, then it will work. It would still be nvidia gpu specific though.
If you log in (preferably as another user) to another tty (Cntrl + Alt + F2/3/4/5), and then run dbus-run-session startplasma-wayland, does that work?
Sometimes just startplasma-wayland works, which used to work for me but didn't work for me this time.
Then, you should be able to switch back to the original KDE session, which continues to work normally, at least it does for me. Both sessions should have shared access to the GPU, as well. You can then probably run sunshine in that second instance of KDE, while the monitor can be attached to tty1 or tty2, whichever one is the default where KDE is put.
Then, you would probably want to configure sunshine to work even when the screen is locked, that way you can lock the second session with Win + L, but it can still be interacted with remotely via sunshine.
EDIT: I only am somewhat confident that this setup will work, I haven't tested it personally.
Debian has old software and doesn’t support some newer hardware. Even the latest version, Trixie, is still very far behind. I realize this now.
Debian has backports, which enable you to get select versions of newer software. Relevant to your case, you can get a newer version of the kernel, drivers, and other things relevant to hardware support.
Might be a bug, so we can troubleshoot to try to figure it out.
If you visit about:processes, is there any website or extension taking up a lot of system resources?
In addition to that, you can try launching firefox in safe/troubleshooting mode. 3 bars in the top right > Help > Troubleshooting mode
This restarts firefox with all addons, extensions, and themes disabled.
For further troubleshooting, also try:
Go to about:profiles, and create and launch a new one. This is a more complete reset, since it also resets all settings, about:config options, and similar.
After creating a new profile, you can play around with rebuilding your current firefox config, adding extensions and changing settings.
Once you do that it puts the cert in /etc/letsencrypt/live/ so you can then do whatever you want with it. You would have to handle distribution manually.
One thing I read about is that Ubuntu provides unattended updates, so it can automatically update packages and restart the server (that seems a bit too far ;) ). It’s probably possible on Debian but not out of the box.
Ubuntu automatically has unattended upgrades, which makes I think makes it a popular choice for VPS providers to push (beyond being popular in corporate/institutions overall), since they don't have to worry about users forgetting security updates. However, it doesn't enable automatic reboots. But, it does look like automatic restarts of services updated via unattended upgrades is done, but only as of Ubuntu 24.
Another thing to note is that Ubuntu has updates that are explicitly for security, and then everything else, including more general bugfixes and program updates with additional features. By default, unattended upgrades on Ubuntu only do security updates.
Of course, both a unattended upgrades and automatic reboots are possible on Debian (same software, Ubuntu just preconfigures it), although default configurations can vary. I wouldn't be suprised if a VPS provider was shipping a default Debian configuration that enabled automatic upgrades.
On Debian, for the most part, ALL updates are only for security issues or severe bugfixes (program crashes or the like). Debian, for the most part, doesn't do minor bugfixes at all, or do program feature updates. I prefer this model, since it's easier to manage than having separate types of package updates. It ensures absolute stability, a guarantee that the system tomorrow will behave the same as it did yesterday, while still enabling automatic security updates. This model is ideal for a server I don't want to babysit, or for your grandpa who loses his mind when the button he is supposed to click was moved one spot over.
In addition to that, I like the policy of automatic reboots. With the stable, slow moving nature of both distros, it's safe to automatically reboot to ensure that kernel vulnerabilities, or vulnerabilities in other critical systems are fixed. Automatic updates and reboots can be the difference between someone being able to escape a docker container or someone not being able to.
The main problem is that if a third party repo and Debian provide the same package, and the system is configured to prefer the third party repo, then you can be installing a potential dependency to the rest of your system that isn't actually tested against your system, or compatible.
You have to be really careful to ensure that the programs in the repo are actually built and designed for your system, and also that the your system does not default to installing them.
Third party repos also break the guarantee of stability that automatic updates depend on. Third party repos don't have a separate security channel, so Ubuntu will probably avoid touching them, even if critical security fixes are needed. Debian will update them, but unlike Debian's packages, the overall program updates won't be guaranteed to be behave the same due to potential major/minor version changes.
For example, if you get Docker from docker's repo instead of Debian's/Ubuntu's, now your version of docker can no longer auto update and receive potential security fixes safely.
Overall, I prefer Debian but Ubuntu is fine. If I was in an environment that used Ubuntu already, I would also just use Ubuntu. If you are already using Debian, then Debian is probably preferable.
Only in electron based editors AFAIK. It requires an integrated browser engine, and electron already is an integrated browser engine so that makes it easy.
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 install then 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 say when 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.
I want users to be able to install apps, but only from the the gui software manager and apt install in the terminal.
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 apt programs, 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 is sudo, which governs cli programs, but there is also polkit, 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:
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 pkgcli to interact with it from the command line, and it still uses polkit.
And put this in /etc/polkit-1/rules.d/10-enable-rootless-packagekit.rules
This 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.
I feel obligated to give some context about why they are excited, since the article seems to be targeting people who understand. Specifically, this part:
There are two theoretical kernel architectures: Microkernel, and monolithic kernel.
The primary advantage of a monolithic kernel is performance. All modern operating systems a monolithic kernels [1]. The big advantage of a microkernel is security.
With a monolithic kernel, almost everything runs privileged, in the kernel. Hardware interactions, drivers, firewalls, various processes. The big disadvantage of this, is that if any of those components have a bug and crash, it bluescreens.
The best example was the crowdstrike blue screen of death issues: https://en.wikipedia.org/wiki/2024_CrowdStrike-related_IT_outages . Crowdstrike runs at the kernel level (kind of like kernel level anticheat), and it had a bug, causing BSOD's everywhere. Of course, this is a fairly drastic example. Anecdotally, I have noticed in an increase in random BSOD's from people who have kernel level anticheat installed. Of course, the average user never whines and you have to pull this out of them, they just treat this as "normal".
With a microkernel, things are different. Everything is separated out, running as less privileged processes. This has big security implications since, it means that pwning one component of the Linux kernel, wouldn't own the whole kernel. That has been how so many of the recent Linux kernel root exploits have happened, where subsystems, rather than the entire kernel are vulnerable. With a microkernel, the possibility of an exploit in say, the containerization/sandboxing features, wouldn't lead to a root exploit on the host. SImilarly, components like device or filesystem drivers could be put in userspace as well, enabling much better security and isolation.
[1], well, sometimes people try to argue that the difference between a microkernel and a monolithic kernel is about codebase organization, optimizing for development velocity. Windows, and Mac are called "hybrid kernels", because the core kernel code is separated from things like drivers, enabling people to develop them separately. This used to be a bigger deal back in the day, since it enabled faster development for things like peripherals.
But there is no security or correctness benefit, so I consider them a monolithic kernel. In addition to that, "true" monolithic kernels (like Linux) have since innovated. While being open source may not be a big deal to us today, it was an innovation on it's own, that enabled people to include the firmware/drivers in the kernel directly (albeit, sometimes as binary blobs distributed in linux-firmware). In addition to that, there is also dkms for loading out of tree kernel modules, or epbf which enables you to run arbitrary code with ring 0 level privileges... but in such a way that it also doesn't hard crash the system when there is a bug.
Yes, although there have been a few CVE's related to escalating privileges or breaking out of the sandbox. You're going to want to keep those updating and keep on top of those.
There is one concern, in that the nix store (
/nix/store) is world readable. It is not world writable, which is good, but there is a problem in that secrets can potentially be copied into the nix store. If you copy a file containing environment variables or the like into the nix store, it could theoretically be found it. This one is on the users of nix to be careful of.With Nix flakes, the entire git repo that the flake originates from is copied into the nix store. Meaning if you have a nix flake in something that is supposed to be a private repo, or contains tracked sensitive data (untracked files are not copied into the nix store), then it could be found and inspected by other users.
My big concern with multi user in this case is not merely the Nix daemon though, but also Linux itself. Linux has been hit with a LOT of privilege escalation and container escape issues over the past few years, and many of them have been zero day's. Given this, I no longer really have the same level of trust for Linux with regards to multi user isolation, for in cases like these.
Of course, in academic computing, I would probably just do multi user anyways, for simplicity. If you install tracking and monitoring, then you can attach malicious actions to identities. Because every user is registered and operates within the institution, if they break the terms of use for computing equipment, then you can punish them within the institution, or pursue greater legal action.
And then, you also would want to enforce 2FA to help minimize stolen accounts. While that can still be phished via fake login pages that ask for 2FA, it handles most of the things. Isolate the server via firewalls, and then it becomes a small enough target that doesn't have enough value (assuming of course, your research isn't too valuable and worth targeting), and you mostly don't have to worry about it.
Sure, people will root it. But then they'll send you a nicely worded email explaining how they rooted it and how to fix it. Which is what my friend did at my school, on our shared ssh server. Just keep it updated to handle the low hanging fruit.
However, if you are going to give it to untrusted users with unknown or temporary (not within the institution) identities, then things change, and you have to take it a lot more seriously. I no longer have confidence in just Linux's user based isolation.
The first line solution I would go to, is to put users in containers and mount the nix store (and nix daemon) in and out. Something like a docker/podman container or Incus container. Of course, container escapes are still possible. If you are even more concerned about those, then you would want virtual machines. It is still possible to share the nix store between virtual machines, but it is more complicated.
In addition to that, virtual machines have a performance tradeoff (usually 95% or more of the host's performance though), but there might be issues with sharing GPU compute resources among virtual machines, depending on the hardware you are using. Enterprise GPU's usually support it though.
Idk..
Maybe you can use a VPN that acts a public ipv4 address so you can get to ipv4 only stuff reliably?
or you can use one of the public free 6to4 gateways?
Could it be that rubygems does not support ipv6?
Some sites, even big sites don't support it: https://areweipv6yet.com/
According to the above, Github doesn't properly support it yet.
Preinstall wine
Enable wine as the default app to open exes,.
then, when you double click on an exe you downloaded in your file explorer, it will launch and open.
Many of the user friendly Linux distros do this.
Of course there are caveats, in that if you run an installer, it might not show up in your desktop or so on. And any programs that need admin or have heavy drm also won't run.
Im addition to that, I dislike the model of downloading exes from the internet. Here is the other comment with my thoughts: https://programming.dev/post/48941029/23338730
There is the excellent chess programming wiki, but unfortunately it does error 503 for me right now.
Here is the archive: https://web.archive.org/web/20250302091125/https://www.chessprogramming.org/Main_Page
Main site: https://www.chessprogramming.org/Main_Page
It has some pretty good resources to get started, and all the techniques being used.
Debian has a policy of only cherry picking security updates, or critical bugfixes, in order to ensure maximum system stability. In general, they don't do entire program updates or additional features. For the 4 year lifecycle of a Debian release, it will behave the same as it did yesterday.
As of today, current version of rsync in Debian's stable's packages is 3.4.1: https://packages.debian.org/stable/rsync (archive).
The versions with significant LLM assistance are 3.4.3 and later.
Yes, and the above solution I laid out is a way to get around that, that potentially dodges the complexity of configuring a truly headless session. It's possible to run two KDE sessions at once, next to eachother, and then simply put one on the main display, with the second being "headless", and not shown.
I started fiddling with the above setup I described, actually installing and testing sunshine. Unfortunately I hit some hiccups. I got sunshine to run, but with no input, and then then it attached to the wrong KDE, even though it was streaming the correct one initially. Now I'm running the same KDE session as a different user (since I was on the same user before), but having pairing issues, but I suspect these are because moonlight is seeing the wrong SSL cert, since the sunshine as a new user generated a new cert.
Do you actually need the headless backend? Or do you need a background session that doesn't interfere with the main session?
If you don't have internet, which you may need for some of the fixes mentioned here, you can try tethering, which is where you share a phone's internet with a computer over a wired connection.
https://wiki.archlinux.org/title/Android_tethering
https://wiki.archlinux.org/title/IPhone_tethering
Although, these might depend on NetworkManager, although they might not.
Second comment:
https://docs.lizardbyte.dev/projects/sunshine/v0.21.0/about/guides/linux/headless_ssh.html
There is also this guide, but it is specific for Xorg and Nvidia gpus. But I suspect that if you replace the
startxhere withstartplasma-waylandordbus-run-session startplasma-wayland, then it will work. It would still be nvidia gpu specific though.If you log in (preferably as another user) to another tty (Cntrl + Alt + F2/3/4/5), and then run
dbus-run-session startplasma-wayland, does that work?Sometimes just
startplasma-waylandworks, which used to work for me but didn't work for me this time.Then, you should be able to switch back to the original KDE session, which continues to work normally, at least it does for me. Both sessions should have shared access to the GPU, as well. You can then probably run sunshine in that second instance of KDE, while the monitor can be attached to tty1 or tty2, whichever one is the default where KDE is put.
Then, you would probably want to configure sunshine to work even when the screen is locked, that way you can lock the second session with Win + L, but it can still be interacted with remotely via sunshine.
EDIT: I only am somewhat confident that this setup will work, I haven't tested it personally.
Debian has backports, which enable you to get select versions of newer software. Relevant to your case, you can get a newer version of the kernel, drivers, and other things relevant to hardware support.
Might be a bug, so we can troubleshoot to try to figure it out.
If you visit
about:processes, is there any website or extension taking up a lot of system resources?In addition to that, you can try launching firefox in safe/troubleshooting mode. 3 bars in the top right > Help > Troubleshooting mode
This restarts firefox with all addons, extensions, and themes disabled.
For further troubleshooting, also try:
Go to
about:profiles, and create and launch a new one. This is a more complete reset, since it also resets all settings,about:configoptions, and similar.After creating a new profile, you can play around with rebuilding your current firefox config, adding extensions and changing settings.
Certbot?
It can automate provisioning of certificates using DNS-01 challenges, which have wildcard certificates.
https://eff-certbot.readthedocs.io/en/stable/using.html#dns-plugins
Example tutorial: https://www.digitalocean.com/community/tutorials/how-to-create-let-s-encrypt-wildcard-certificates-with-certbot
Once you do that it puts the cert in
/etc/letsencrypt/live/so you can then do whatever you want with it. You would have to handle distribution manually.If you want to automate stuff across of a bunch of machines at once, I recommend Ansible: https://docs.ansible.com/projects/ansible/latest/index.html
https://libregamewiki.org/Roguelike_games
There are more games on there, but I have been meaning to try the roguelike stuff out.
Ubuntu automatically has unattended upgrades, which makes I think makes it a popular choice for VPS providers to push (beyond being popular in corporate/institutions overall), since they don't have to worry about users forgetting security updates. However, it doesn't enable automatic reboots. But, it does look like automatic restarts of services updated via unattended upgrades is done, but only as of Ubuntu 24.
Another thing to note is that Ubuntu has updates that are explicitly for security, and then everything else, including more general bugfixes and program updates with additional features. By default, unattended upgrades on Ubuntu only do security updates.
Of course, both a unattended upgrades and automatic reboots are possible on Debian (same software, Ubuntu just preconfigures it), although default configurations can vary. I wouldn't be suprised if a VPS provider was shipping a default Debian configuration that enabled automatic upgrades.
On Debian, for the most part, ALL updates are only for security issues or severe bugfixes (program crashes or the like). Debian, for the most part, doesn't do minor bugfixes at all, or do program feature updates. I prefer this model, since it's easier to manage than having separate types of package updates. It ensures absolute stability, a guarantee that the system tomorrow will behave the same as it did yesterday, while still enabling automatic security updates. This model is ideal for a server I don't want to babysit, or for your grandpa who loses his mind when the button he is supposed to click was moved one spot over.
In addition to that, I like the policy of automatic reboots. With the stable, slow moving nature of both distros, it's safe to automatically reboot to ensure that kernel vulnerabilities, or vulnerabilities in other critical systems are fixed. Automatic updates and reboots can be the difference between someone being able to escape a docker container or someone not being able to.
There is one thing to note, is that adding additional repos (or PPA's which technically you aren't supposed to work on Debian), can be dangerous, and you have to be careful: https://wiki.debian.org/DontBreakDebian/#Don.27t_make_a_FrankenDebian
The main problem is that if a third party repo and Debian provide the same package, and the system is configured to prefer the third party repo, then you can be installing a potential dependency to the rest of your system that isn't actually tested against your system, or compatible.
You have to be really careful to ensure that the programs in the repo are actually built and designed for your system, and also that the your system does not default to installing them.
Third party repos also break the guarantee of stability that automatic updates depend on. Third party repos don't have a separate security channel, so Ubuntu will probably avoid touching them, even if critical security fixes are needed. Debian will update them, but unlike Debian's packages, the overall program updates won't be guaranteed to be behave the same due to potential major/minor version changes.
For example, if you get Docker from docker's repo instead of Debian's/Ubuntu's, now your version of docker can no longer auto update and receive potential security fixes safely.
Overall, I prefer Debian but Ubuntu is fine. If I was in an environment that used Ubuntu already, I would also just use Ubuntu. If you are already using Debian, then Debian is probably preferable.
Only in electron based editors AFAIK. It requires an integrated browser engine, and electron already is an integrated browser engine so that makes it easy.
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.What made moodle frustrating?
I have also heard the opposite take, that canvas sucks and moodle is great.
Did you use it as a student/user, or as an administrator?