JuNest: Arch Linux-based distro that runs on any Linux OS, without root access(fsquillace.github.io)
fsquillace.github.io
JuNest: Arch Linux-based distro that runs on any Linux OS, without root access
http://fsquillace.github.io/junest-site/
65 comments
> On a philosophical note, I second vortico's question of why common Linux distros require root access to be at all usable. In particular, how did it come to not being able to install a package without sudo?
Previously:
http://adamierymenko.com/privileged-ports-are-causing-climat...
https://news.ycombinator.com/item?id=14712576
TLDR; "You probably just realized that without the privileged ports restriction everything meaningful on a Unix system would not have to run as root and you could at the very least do a much better job of securing system services."
Previously:
http://adamierymenko.com/privileged-ports-are-causing-climat...
https://news.ycombinator.com/item?id=14712576
TLDR; "You probably just realized that without the privileged ports restriction everything meaningful on a Unix system would not have to run as root and you could at the very least do a much better job of securing system services."
Thank you! This is the sole comment in the thread that answers the question I was asking.
Also from the article:
>Wait... sudo? Giving sudo rights means you might as well not have separate users at all.
>Bollocks!
...and how we got there is was my question.
Still, there's more mystery. Privileged ports can't explain why the user has to jump through the hoops for software that doesn't need to bind itself to ports.
So, how did it come to packages requiring sudo in most distros?
Also from the article:
>Wait... sudo? Giving sudo rights means you might as well not have separate users at all.
>Bollocks!
...and how we got there is was my question.
Still, there's more mystery. Privileged ports can't explain why the user has to jump through the hoops for software that doesn't need to bind itself to ports.
So, how did it come to packages requiring sudo in most distros?
The confusion comes from a basic misunderstanding most users have about distros and packages.
A Linux distribution package is software ready for you to use. It contains static, "pre-installed" software and configuration, and only performs certain actions that your system can't simply read from a file (like adding a user or group). Everything else in the package is exactly the way it should be to "just work".
Changing where the files go would require more complex decisions to make everything "just work". So because we can't change where the files go, any old user can't install it, because that would mean the possibility of overwriting files not owned by that user, or system files.
So you need to put the files in privileged locations, but not allow the user to change where that goes. 'sudo' allows this to happen. But why do we even need to type 'sudo' if your [desktop] user will always be capable of running some command with 'sudo' anyway? Because sometimes, someone or some thing other than you will try to run a command as root, and you should be the only person that authorizes that. Requiring the command, and the command requiring a password to run, is the simplest way to do this.
All JuNest is doing is putting an entire copy of a Linux distribution in your home directory, so everything is owned by you. There are no privileged files, but more importantly, if you hose the files, you can just re-install JuNest. If you hosed your main machine, you'd have to reinstall your machine.
A Linux distribution package is software ready for you to use. It contains static, "pre-installed" software and configuration, and only performs certain actions that your system can't simply read from a file (like adding a user or group). Everything else in the package is exactly the way it should be to "just work".
Changing where the files go would require more complex decisions to make everything "just work". So because we can't change where the files go, any old user can't install it, because that would mean the possibility of overwriting files not owned by that user, or system files.
So you need to put the files in privileged locations, but not allow the user to change where that goes. 'sudo' allows this to happen. But why do we even need to type 'sudo' if your [desktop] user will always be capable of running some command with 'sudo' anyway? Because sometimes, someone or some thing other than you will try to run a command as root, and you should be the only person that authorizes that. Requiring the command, and the command requiring a password to run, is the simplest way to do this.
All JuNest is doing is putting an entire copy of a Linux distribution in your home directory, so everything is owned by you. There are no privileged files, but more importantly, if you hose the files, you can just re-install JuNest. If you hosed your main machine, you'd have to reinstall your machine.
>Changing where the files go would require more complex decisions to make everything "just work".
Since when things "just working" has been a core design philosophy of *nix systems?
Also, you do realize that the end result is that the things that should work just don't?
In my opinion, it's a design failure that [download the source - unpack - configure - make - make install] is a viable path to get something to work, but [yum install]" is not.
Since when things "just working" has been a core design philosophy of *nix systems?
Also, you do realize that the end result is that the things that should work just don't?
In my opinion, it's a design failure that [download the source - unpack - configure - make - make install] is a viable path to get something to work, but [yum install]" is not.
It's only certain package managers.
For instance, pkgsrc and portage don't require root access.
The "certain package managers" happen to be "every single package manager I've encounter on a system I don't own".
I'll be content in knowing the history of "apt-get install" requiring sudo.
There's is this thread, but I don't understand how nobody in charge of anything ever figured this all of that this design is bollocks if you want to have true multi-tenancy on a system.
I'll be content in knowing the history of "apt-get install" requiring sudo.
There's is this thread, but I don't understand how nobody in charge of anything ever figured this all of that this design is bollocks if you want to have true multi-tenancy on a system.
Nix also doesn't
> In particular, how did it come to not being able to install a package without sudo?
You can on Fedora via `pkcon install <pkg>`.
You can on Fedora via `pkcon install <pkg>`.
Won't that just bring up a system (polkit?) password dialog (so no sudo, but you still need an admin password)?
You can configure polkit rules to allow unprivileged users to install packages. It will, for example, ask for the user's password.
But this doesn't really solve the issue of allowing unprivileged users to install software from the package managers just for them.
But this doesn't really solve the issue of allowing unprivileged users to install software from the package managers just for them.
Not for signed packages, see https://www.reddit.com/r/Fedora/comments/574jmg/potential_bu...
Interesting/weird/scary
That's just leveraging polkit rather than sudo. It still requires delegated root access. The parent is asking why an unprivileged user can't run
yum install --user <pkg>
And have the package expand in, say, ~/.local
yum install --user <pkg>
And have the package expand in, say, ~/.local
> yum install --user <pkg>
> And have the package expand in, say, ~/.local
One problem is that many binaries have their paths (e.g. /usr/share/<pkg>/ or /etc/<pkg>) hard-coded, meaning they aren't relocatable.
For desktop applications Flatpak will solve this: It has the --user flag just as you suggested.
> And have the package expand in, say, ~/.local
One problem is that many binaries have their paths (e.g. /usr/share/<pkg>/ or /etc/<pkg>) hard-coded, meaning they aren't relocatable.
For desktop applications Flatpak will solve this: It has the --user flag just as you suggested.
It does?
$ flatpak --version Flatpak 0.9.7
$ flatpak --help Usage: flatpak [OPTION...] COMMAND
Builtin Commands: Manage installed apps and runtimes install Install an application or runtime update Update an installed application or runtime uninstall Uninstall an installed application or runtime list List installed apps and/or runtimes info Show info for installed app or runtime
Running applications run Run an application override Override permissions for an application make-current Specify default version to run enter Enter the namespace of a running application
Manage file access document-export Grant an application access to a specific file document-unexport Revoke access to a specific file document-info Show information about a specific file document-list List exported files
Manage remote repositories remotes List all configured remotes remote-add Add a new remote repository (by URL) remote-modify Modify properties of a configured remote remote-delete Delete a configured remote remote-ls List contents of a configured remote
Build applications build-init Initialize a directory for building build Run a build command inside the build dir build-finish Finish a build dir for export build-export Export a build dir to a repository build-bundle Create a bundle file from a build directory build-import-bundle Import a bundle file build-sign Sign an application or runtime build-update-repo Update the summary file in a repository build-commit-from Create new commit based on existing ref repo Print information about a repo
Help Options: -h, --help Show help options
Application Options: --version Print version information and exit --default-arch Print default arch and exit --supported-arches Print supported arches and exit --gl-drivers Print active gl drivers and exit -v, --verbose Print debug information during command processing --ostree-verbose Print OSTree debug information during command processing
$ flatpak --version Flatpak 0.9.7
$ flatpak --help Usage: flatpak [OPTION...] COMMAND
Builtin Commands: Manage installed apps and runtimes install Install an application or runtime update Update an installed application or runtime uninstall Uninstall an installed application or runtime list List installed apps and/or runtimes info Show info for installed app or runtime
Running applications run Run an application override Override permissions for an application make-current Specify default version to run enter Enter the namespace of a running application
Manage file access document-export Grant an application access to a specific file document-unexport Revoke access to a specific file document-info Show information about a specific file document-list List exported files
Manage remote repositories remotes List all configured remotes remote-add Add a new remote repository (by URL) remote-modify Modify properties of a configured remote remote-delete Delete a configured remote remote-ls List contents of a configured remote
Build applications build-init Initialize a directory for building build Run a build command inside the build dir build-finish Finish a build dir for export build-export Export a build dir to a repository build-bundle Create a bundle file from a build directory build-import-bundle Import a bundle file build-sign Sign an application or runtime build-update-repo Update the summary file in a repository build-commit-from Create new commit based on existing ref repo Print information about a repo
Help Options: -h, --help Show help options
Application Options: --version Print version information and exit --default-arch Print default arch and exit --supported-arches Print supported arches and exit --gl-drivers Print active gl drivers and exit -v, --verbose Print debug information during command processing --ostree-verbose Print OSTree debug information during command processing
Please consider this question before making one-off throwaway accounts here, "Does this really need to be said, if I cannot say it with my real identity?"
Is it more important to you to get your comment posted, or is it more important that you aren't held to account for your statements?
Is it more important to you to get your comment posted, or is it more important that you aren't held to account for your statements?
Try
$ flatpak install --help
$ flatpak install --help
The Polkit delegation is fine-grained. All it allows is managing packages.
Installing packages locally is a management nightmare from a systems administration point of view, and it does not fit the way package managers like APT and RPM work.
In most cases, a machine is used by a single user so it makes sense to allow global package installation, even if the user does not have root privileges.
Installing packages locally is a management nightmare from a systems administration point of view, and it does not fit the way package managers like APT and RPM work.
In most cases, a machine is used by a single user so it makes sense to allow global package installation, even if the user does not have root privileges.
NixOS makes this possible.
The package management model in NixOS looks like what it should have been elsewhere.
Do you know why it's not yet the case?
Do you know why it's not yet the case?
> It still requires delegated root access.
Not sure what you mean by that exactly, but the user doesn't need to enter his password or root's for signed packages. See https://www.reddit.com/r/Fedora/comments/574jmg/potential_bu...
Not sure what you mean by that exactly, but the user doesn't need to enter his password or root's for signed packages. See https://www.reddit.com/r/Fedora/comments/574jmg/potential_bu...
You can also set up sudo so that it does not require your password for certain commands, that does not mean you are not still getting root to do a thing that requires root permissions.
It sounds like it has been made relatively "safer" but, the comment you linked says that it's the author's opinion it is a bad idea, because the user is doing something they are not allowed to undo. So you are getting root access, via policy.
Why do you need root access when you could just write the package contents out to a directory you control, and run them without any signatures or policy? (Or even with verifying signatures, why not I guess...)
I'm not asking you personally for a position on this, I'm just explaining how it's different... you are still taking root, only through a safety wrapper. The advantages to this that I can see are 1) the user is encouraged to install signed packages, and 2) the sysadmin is empowered to keep the user's installed packages up-to-date.
Those are maybe compelling, but I don't see major advantages. Give me something like rvm+bundler and I'll be a lot happier. (I don't really want sysadmin to have powers to do things that I can't undo, either!)
It sounds like it has been made relatively "safer" but, the comment you linked says that it's the author's opinion it is a bad idea, because the user is doing something they are not allowed to undo. So you are getting root access, via policy.
Why do you need root access when you could just write the package contents out to a directory you control, and run them without any signatures or policy? (Or even with verifying signatures, why not I guess...)
I'm not asking you personally for a position on this, I'm just explaining how it's different... you are still taking root, only through a safety wrapper. The advantages to this that I can see are 1) the user is encouraged to install signed packages, and 2) the sysadmin is empowered to keep the user's installed packages up-to-date.
Those are maybe compelling, but I don't see major advantages. Give me something like rvm+bundler and I'll be a lot happier. (I don't really want sysadmin to have powers to do things that I can't undo, either!)
> You can also set up sudo so that it does not require your password for certain commands, that does not mean you are not still getting root to do a thing that requires root permissions.
The difference is, that this is configured by default on Fedora.
> Why do you need root access when you could just write the package contents out to a directory you control, and run them without any signatures or policy?
Because applications have their paths hard-coded all over the place. Also some packages (e. g. webservers running on port 80) wouldn't work without root anyway.
The difference is, that this is configured by default on Fedora.
> Why do you need root access when you could just write the package contents out to a directory you control, and run them without any signatures or policy?
Because applications have their paths hard-coded all over the place. Also some packages (e. g. webservers running on port 80) wouldn't work without root anyway.
"By default" is just not very convincing for me. I know that RedHat has some very qualified people working for them, but the user is getting root and doing root things, regardless of whether or not they enter their password, or if the distro has deigned that it's OK.
RedHat has some very peculiar ideas about security, and I'm not saying that in a bad way. Someone decided that this was OK. In the same way, OpenShift (another RedHat product, their Kubernetes distro) decided that it was unsafe to allow users with "project admin" rights to create a DaemonSet within their own project.
After reading their position, I have to say I agree (DaemonSets run with a higher priority than ReplicaSet, so a malicious user could use their Project Admin privileges to swamp an entire cluster, preventing other pods from running. You need the Cluster Admin role for this.)
The fact this is configured by default, does not mean much to me.
If you trust Fedora to review every package for security vulnerabilities before it is signed and released, that's fine! You should, if you are using their distribution. My InfoSec group does not grant root privileges to non-root users without a good reason, and I am certain even explained properly, they would balk and groan about this policy. It is a potential avenue for privilege escalation, and the only reason it could be safe is because of the vigilance of Fedora team. That's convenient, but not very "belt and suspenders" in my opinion.
> applications have their paths hard-coded all over the place
This is open-source, if an application has a hard-coded path, it can be fixed. If it isn't open-source, I'd assume RH won't sign the packages. Good software remains portable by making these things configurable in a .conf or environment variable (and good upstream dev teams will accept patches to make their software more portable).
That is surely a problem as you have highlighted and good software shouldn't have hard-coded paths all over the place without reason. So we shouldn't optimize for that case.
> Also some packages (e. g. webservers running on port 80) wouldn't work without root anyway.
That is by design, that is why those are called privileged ports (<1024.) Maybe it is inconvenient, but how does allowing the user to install a web server as root and start listening on port 80, improve any part of this particular user story?
What exactly is your user going to do with a running web server listening on Port 80 when they still need to be added to httpd group (by root) or they can't write to /var/www, and what's the point of letting them install the package when they still can't make adjustments to /etc/httpd.conf without root access?
RedHat has some very peculiar ideas about security, and I'm not saying that in a bad way. Someone decided that this was OK. In the same way, OpenShift (another RedHat product, their Kubernetes distro) decided that it was unsafe to allow users with "project admin" rights to create a DaemonSet within their own project.
After reading their position, I have to say I agree (DaemonSets run with a higher priority than ReplicaSet, so a malicious user could use their Project Admin privileges to swamp an entire cluster, preventing other pods from running. You need the Cluster Admin role for this.)
The fact this is configured by default, does not mean much to me.
If you trust Fedora to review every package for security vulnerabilities before it is signed and released, that's fine! You should, if you are using their distribution. My InfoSec group does not grant root privileges to non-root users without a good reason, and I am certain even explained properly, they would balk and groan about this policy. It is a potential avenue for privilege escalation, and the only reason it could be safe is because of the vigilance of Fedora team. That's convenient, but not very "belt and suspenders" in my opinion.
> applications have their paths hard-coded all over the place
This is open-source, if an application has a hard-coded path, it can be fixed. If it isn't open-source, I'd assume RH won't sign the packages. Good software remains portable by making these things configurable in a .conf or environment variable (and good upstream dev teams will accept patches to make their software more portable).
That is surely a problem as you have highlighted and good software shouldn't have hard-coded paths all over the place without reason. So we shouldn't optimize for that case.
> Also some packages (e. g. webservers running on port 80) wouldn't work without root anyway.
That is by design, that is why those are called privileged ports (<1024.) Maybe it is inconvenient, but how does allowing the user to install a web server as root and start listening on port 80, improve any part of this particular user story?
What exactly is your user going to do with a running web server listening on Port 80 when they still need to be added to httpd group (by root) or they can't write to /var/www, and what's the point of letting them install the package when they still can't make adjustments to /etc/httpd.conf without root access?
> but the user is getting root
No, he's not.
> My InfoSec group does not grant root privileges to non-root users without a good reason
This doesn't either.
> This is open-source, if an application has a hard-coded path, it can be fixed. If it isn't open-source, I'd assume RH won't sign the packages. Good software remains portable by making these things configurable in a .conf or environment variable (and good upstream dev teams will accept patches to make their software more portable).
> That is surely a problem as you have highlighted and good software shouldn't have hard-coded paths all over the place without reason. So we shouldn't optimize for that case.
I agree, but I guess it's a lot of work and that's why no one has done it yet.
No, he's not.
> My InfoSec group does not grant root privileges to non-root users without a good reason
This doesn't either.
> This is open-source, if an application has a hard-coded path, it can be fixed. If it isn't open-source, I'd assume RH won't sign the packages. Good software remains portable by making these things configurable in a .conf or environment variable (and good upstream dev teams will accept patches to make their software more portable).
> That is surely a problem as you have highlighted and good software shouldn't have hard-coded paths all over the place without reason. So we shouldn't optimize for that case.
I agree, but I guess it's a lot of work and that's why no one has done it yet.
> but the user is getting root
> No, he's not.
https://isc.sans.edu/forums/diary/Is+the+polkit+Grinch+Going...
"""
Polkit works differently then sudo. With sudo, I configure which software a user is allowed to run as root (or another user). With polkit, I configure which privileges a user is allowed to take advantage of while running a particular piece of software.
The problem pointed out by Alert Logic is two fold. First of all, the default polkit configuration on many Unix systems (e.g. Ubuntu), does not require authentication. Secondly, the polkit configuration essentially just maps the "wheels" group, which is commonly used for sudo users, to the polkit "Admin". This gives users in the "wheel" group access to administrative functions, like installing packages, without having to enter a password.
The main risk is privilege escalation. With sudo, an attacker would have to enter the user's password after compromising a lesser user account in the wheel group. With polkit, all it takes is to install a package using the polkit tool "pkcon", which takes advantage of the loose polkit configuration to install packages.
"""
This is from 2014. What has changed since then? Maybe saying "the user gets root" is hyperbole, but the user gains a set of privileges to use in pkcon, via polkit, that they would not normally have. That is the definition of privilege escalation. It's just that in this case, it's hopefully done safely, and so "privilege escalation" does not necessarily carry the connotation of "security vulnerability." It's only one step away: a vulnerability is discovered in pkcon, and now it is an actual security vulnerability.
But you have some bridges to cross before you convince me that it is safe. My Debian systems don't have an equivalent route for users to escalate their privileges when they haven't been granted them explicitly by a system admin.
Edit: and here's a thread from 2009, when this was already the case
https://lists.fedoraproject.org/archives/list/[email protected]...
> It certainly seems like an easy path to a denial of service: just install everything and run the machine out of disk space.
So, it is already potentially unsafe for the very same reason that my earlier example, DaemonSet, is unsafe for mere project admin! It presents a clear path to DoS for users on any system that is remotely short on disk.
> I agree, but I guess it's a lot of work and that's why no one has done it yet.
If you think that configuring PolKit and SELinux properly for every system that needs to go outside of the policies that RH considers to be sane default, is not a lot of work... I can't really provide an example from inside of the last 10 years to refute that.
The RedHat mark has literally saved me from doing convenient-but-unsafe things at least dozens of times, this seems out of character for them. But it's been policy since at least 2009, and I haven't heard of it being used in any major breaches, so maybe it's actually not so bad.
> No, he's not.
https://isc.sans.edu/forums/diary/Is+the+polkit+Grinch+Going...
"""
Polkit works differently then sudo. With sudo, I configure which software a user is allowed to run as root (or another user). With polkit, I configure which privileges a user is allowed to take advantage of while running a particular piece of software.
The problem pointed out by Alert Logic is two fold. First of all, the default polkit configuration on many Unix systems (e.g. Ubuntu), does not require authentication. Secondly, the polkit configuration essentially just maps the "wheels" group, which is commonly used for sudo users, to the polkit "Admin". This gives users in the "wheel" group access to administrative functions, like installing packages, without having to enter a password.
The main risk is privilege escalation. With sudo, an attacker would have to enter the user's password after compromising a lesser user account in the wheel group. With polkit, all it takes is to install a package using the polkit tool "pkcon", which takes advantage of the loose polkit configuration to install packages.
"""
This is from 2014. What has changed since then? Maybe saying "the user gets root" is hyperbole, but the user gains a set of privileges to use in pkcon, via polkit, that they would not normally have. That is the definition of privilege escalation. It's just that in this case, it's hopefully done safely, and so "privilege escalation" does not necessarily carry the connotation of "security vulnerability." It's only one step away: a vulnerability is discovered in pkcon, and now it is an actual security vulnerability.
But you have some bridges to cross before you convince me that it is safe. My Debian systems don't have an equivalent route for users to escalate their privileges when they haven't been granted them explicitly by a system admin.
Edit: and here's a thread from 2009, when this was already the case
https://lists.fedoraproject.org/archives/list/[email protected]...
> It certainly seems like an easy path to a denial of service: just install everything and run the machine out of disk space.
So, it is already potentially unsafe for the very same reason that my earlier example, DaemonSet, is unsafe for mere project admin! It presents a clear path to DoS for users on any system that is remotely short on disk.
> I agree, but I guess it's a lot of work and that's why no one has done it yet.
If you think that configuring PolKit and SELinux properly for every system that needs to go outside of the policies that RH considers to be sane default, is not a lot of work... I can't really provide an example from inside of the last 10 years to refute that.
The RedHat mark has literally saved me from doing convenient-but-unsafe things at least dozens of times, this seems out of character for them. But it's been policy since at least 2009, and I haven't heard of it being used in any major breaches, so maybe it's actually not so bad.
> the user gains a set of privileges to use in pkcon, via polkit, that they would not normally have. That is the definition of privilege escalation.
But they HAVE this privilege (installing packages) normally in Fedora, so it isn't privilege escalation.
> just install everything and run the machine out of disk space.
Or just create large empty files??
But they HAVE this privilege (installing packages) normally in Fedora, so it isn't privilege escalation.
> just install everything and run the machine out of disk space.
Or just create large empty files??
> But they HAVE this privilege (installing packages) normally in Fedora, so it isn't privilege escalation.
They don't have permission to write files as root without the help of polkit and pkcon. They can write files as root with the polkit policy's help. Broadly, or not... intentionally, or not! As an outsider coming from another distro, I would argue that policy does not follow the "principle of least surprise."
Maybe long-time RH users are already not surprised, it looks like this is in no way a recent change.
> Or just create large empty files??
If you set up sensible per-user disk quotas, you will prevent this. But if the user can write new files to the disk that are owned by root via polkit, then that would enable them to circumvent your per-user disk quotas. They will not own the files that pkcon writes via polkit.
(For a second I was going to suggest it would be worse if they did own the file, because of setuid bits... but then I remembered where this conversation started, and what side of this debate I'm supposed to be on. ;)
Also a setuid bit on a file that you own would only enable you to escalate your privileges to... yourself. I'm sure any packages that have setuid bits are at the top of Fedora's security audit list, though... if you installed a package that installs a binary with setuid bits, that's another possible avenue for privilege escalation vulnerability that you did not have before PolKit opened the window for you.
They don't have permission to write files as root without the help of polkit and pkcon. They can write files as root with the polkit policy's help. Broadly, or not... intentionally, or not! As an outsider coming from another distro, I would argue that policy does not follow the "principle of least surprise."
Maybe long-time RH users are already not surprised, it looks like this is in no way a recent change.
> Or just create large empty files??
If you set up sensible per-user disk quotas, you will prevent this. But if the user can write new files to the disk that are owned by root via polkit, then that would enable them to circumvent your per-user disk quotas. They will not own the files that pkcon writes via polkit.
(For a second I was going to suggest it would be worse if they did own the file, because of setuid bits... but then I remembered where this conversation started, and what side of this debate I'm supposed to be on. ;)
Also a setuid bit on a file that you own would only enable you to escalate your privileges to... yourself. I'm sure any packages that have setuid bits are at the top of Fedora's security audit list, though... if you installed a package that installs a binary with setuid bits, that's another possible avenue for privilege escalation vulnerability that you did not have before PolKit opened the window for you.
> They don't have permission to write files as root without the help of polkit and pkcon. They can write files as root with the polkit policy's help. Broadly, or not... intentionally, or not! As an outsider coming from another distro, I would argue that policy does not follow the "principle of least surprise."
There are other services running which create files as root on other distros, too. Have a look in /tmp for example.
> If you set up sensible per-user disk quotas, you will prevent this.
If you are able to set-up per-user disk quotas, you're able to also change the policy.
There are other services running which create files as root on other distros, too. Have a look in /tmp for example.
> If you set up sensible per-user disk quotas, you will prevent this.
If you are able to set-up per-user disk quotas, you're able to also change the policy.
> Or just create large empty files??
You generally separate out any directory that has world/user writable directories and files into separate partitions explicitly to prevent resource exhaustion.
Allowing package installations in manner would be forbidden by any security standard.
You generally separate out any directory that has world/user writable directories and files into separate partitions explicitly to prevent resource exhaustion.
Allowing package installations in manner would be forbidden by any security standard.
Yes, but we're talking about Fedora's default. And in Ubuntu's default for example the home directory isn't even seperate.
See also:
- Nix: purely functional package manager that runs on multiple distros. 7/10 awesome ideas but difficult to work with.
- Guix: like Nix, but with Guile Scheme, and different packages. Seems to require system-wide installation and a daemon; also burdened with “freedom”. ??/10 haven’t tried it, but sounds iffy.
- Linuxbrew: Linux port/fork of the popular Homebrew package manager for macOS. 4/10 same problems as Homebrew itself.
- Gentoo Portage Prefix: build and run Gentoo packages in a $PREFIX, without root and on many different OSs. ??/10 haven’t tried it.
- Nix: purely functional package manager that runs on multiple distros. 7/10 awesome ideas but difficult to work with.
- Guix: like Nix, but with Guile Scheme, and different packages. Seems to require system-wide installation and a daemon; also burdened with “freedom”. ??/10 haven’t tried it, but sounds iffy.
- Linuxbrew: Linux port/fork of the popular Homebrew package manager for macOS. 4/10 same problems as Homebrew itself.
- Gentoo Portage Prefix: build and run Gentoo packages in a $PREFIX, without root and on many different OSs. ??/10 haven’t tried it.
"burdened with [scare quotes] freedom"
Wow. What a terrible way to describe a feature!
FWIW, Guix does not require system-wide installation, but it is strongly recommended to run the daemon as root to benefit from reproducibility mechanisms.
Saying that it sounds "iffy" for something you haven't tried and seem to misunderstand is not reasonable.
[Disclaimer: I'm hacking on Guix since many years and use it at work and privately.]
Wow. What a terrible way to describe a feature!
FWIW, Guix does not require system-wide installation, but it is strongly recommended to run the daemon as root to benefit from reproducibility mechanisms.
Saying that it sounds "iffy" for something you haven't tried and seem to misunderstand is not reasonable.
[Disclaimer: I'm hacking on Guix since many years and use it at work and privately.]
The OP is about package managers that an unprivileged user can deploy by themselves on arbitrary POSIX systems. Guix docs make it sound like it (a) needs root to work best, and (b) only targets GNU/Linux - hence iffy for those purposes.
Re: freedom - One persons feature is another’s useless restriction. I’d rather my package manager have strictly more software available, even if some of that software isn’t guaranteed GPL-compatible.
Re: freedom - One persons feature is another’s useless restriction. I’d rather my package manager have strictly more software available, even if some of that software isn’t guaranteed GPL-compatible.
"guaranteed GPL-compatible"
This is a common misunderstanding. There's much more free software out there than software under the GPL. "Only providing free software" does not mean "only providing software under the GPL or a GPL-compatible license". That would be ludicrous.
Guix does not provide proprietary software and I consider this a feature.
This is a common misunderstanding. There's much more free software out there than software under the GPL. "Only providing free software" does not mean "only providing software under the GPL or a GPL-compatible license". That would be ludicrous.
Guix does not provide proprietary software and I consider this a feature.
I am curious to know what are the problem of homebrew itself ?
As a generic user who has never done anything really complex with it, homebrew is a joy, it has never failed me.
Typically the problem areas would be in versioning of dependencies (in particular, resolving conflicting version requirements for different packages, where dependencies form a DAG rather than a tree) or around install hooks (where installation / removal can't be represented simply by existence / absence of whole files on the filesystem).
Nix is reproducible, supports easy rollbacks, and can manage multiple versions of everything for different projects. You don't have to worry about "works on my machine" or "don't update X right now because Y will break" when collaborating.
pkgsrc: NetBSD package repository that can also be used on Linux, inside any $PREFIX, without root: http://www.pkgsrc.org/
There is 0install too, I have never tried it though.
http://0install.net/
http://0install.net/
Last time I tried Prefix it didn't work or at least wasn't as convenient as I was expecting. I wish I could give more details than that but I can't remember now. I was and still am really excited by software like Prefix, however.
This is the only one of the bunch that I've been able to install some packages on RHEL5 and RHEL3 that I'm stuck with. (And even then, only with too much effort bootstrapping.)
Recommend giving a look at Exherbo's multiarch system.
Gobolinux also had something like that, but ended up mothballing it as they transitioned from /System/Links to /System/Index.
i am not sure if portage would work as an ordinary user, since compiling is made through a sandboxed user which i dont think is accessible through a normal user
I use this at work and it's great if you don't have root access but still want to install packages. (Why do you need to be root to install packages locally on all distros anyway??) The Windows equivalent is MSYS2, where you have a POSIX shell, pacman, and many packages thanks to the active maintainers.
> Why do you need to be root to install packages locally on all distros anyway??
On most distros you just can't install packages locally.
On Fedora you can install packages globally without root btw: Try `pkcon install pidgin` for example.
On most distros you just can't install packages locally.
On Fedora you can install packages globally without root btw: Try `pkcon install pidgin` for example.
https://www.pkgsrc.org/ is another alternative for this sort of thing.
It's because the (distro-location)/bin and /etc directories are owned by and only writable by root by default.
Junest is so useful if your project requires recent compilers or libs and your contributors are under some old Debian Stable or Ubuntu.
Would this be a viable alternative to containers?
from the documentation it sounds like it uses namespaces where available, just like containers. chroot otherwise.
I was actually wondering what advantage this has over a container or chroot. The answer is that it actually is one of those under the hood?
I've tested JuNest extensively (with the idea of getting new gcc compiler features on a cluster running an old red hat version).
Unfortunately, JuNest adds a lot more overhead than containers. Specifically, when it comes to high-throughput network applications. At 10GBit an application running on JuNest used several cores at 100%, while without JuNest (underlying red hat) the app was at 10% cpu load (network i/o bound).
All that load was due to PRoot.
Unfortunately, JuNest adds a lot more overhead than containers. Specifically, when it comes to high-throughput network applications. At 10GBit an application running on JuNest used several cores at 100%, while without JuNest (underlying red hat) the app was at 10% cpu load (network i/o bound).
All that load was due to PRoot.
Have you tried with Linux namespaces instead of PRoot?
https://github.com/fsquillace/junest#linux-namespaces-based
https://github.com/fsquillace/junest#linux-namespaces-based
Yes, it is. Either a magic user-space chroot, a normal chroot or user namespaces.
So is this a form of usermode linux? I'm not enough of a linux wizard to understand linux-on-linux, chroot, etc...
This uses systemd-containers, but can fall back to using a chroot, which requires root.
Usermode linux involves running a linux-kernel as just another piece of software under linux. By telling software to access the usermode linux, you can give it a different "view" of the system. That linux kernel process must communicate with the real-kernel, doing things like forwarding network traffic to the "real" kernels network devices. It introduces overhead.
A chroot interrupts one system call (or set of system calls?), making any program you call think "/" is a different directory. It literally changes root. That being said, all it changes is where programs think the root dir is. If you have software in the chroot that runs as root, it actually runs as root on your entire system. It can do things like load custom kernel modules. It can't break out of the chroot, chroots aren't a security feature.
Containers, like systemd-nspawn, use cgroups along with a more-aggressive chroot-like thing, that gives programs a different view of all system calls, not just calls to the filesystem. This means you can run software as "root" in a container without privilege escalation.
Of course it doesn't need to be a full container. Firejail can use those same mechanisms to do things like isolate just your web browser. https://firejail.wordpress.com/
Usermode linux involves running a linux-kernel as just another piece of software under linux. By telling software to access the usermode linux, you can give it a different "view" of the system. That linux kernel process must communicate with the real-kernel, doing things like forwarding network traffic to the "real" kernels network devices. It introduces overhead.
A chroot interrupts one system call (or set of system calls?), making any program you call think "/" is a different directory. It literally changes root. That being said, all it changes is where programs think the root dir is. If you have software in the chroot that runs as root, it actually runs as root on your entire system. It can do things like load custom kernel modules. It can't break out of the chroot, chroots aren't a security feature.
Containers, like systemd-nspawn, use cgroups along with a more-aggressive chroot-like thing, that gives programs a different view of all system calls, not just calls to the filesystem. This means you can run software as "root" in a container without privilege escalation.
Of course it doesn't need to be a full container. Firejail can use those same mechanisms to do things like isolate just your web browser. https://firejail.wordpress.com/
I used to use systemd-nspawn with a simple distro subtree.
$ systemd-nspawn
Need to be root.oh that's why it doesn't work anymore
On a philosophical note, I second vortico's question of why common Linux distros require root access to be at all usable. In particular, how did it come to not being able to install a package without sudo?
I could download something, compile it, and run it, but not install from a package. It doesn't make sense to me. If I can run it, I should be able to "install" it locally, whatever the word "install" means (obviously, it wouldn't mean writing to directories to which I don't have access otherwise).
JuNest simply proves this point.