5 ms·

> In particular, how did it come to not being able to install a package without sudo? You can on Fedora via `pkcon install <pkg>`.

by jhasse 9y ago

abrowne 9y ago
Won't that just bring up a system (polkit?) password dialog (so no sudo, but you still need an admin password)?
- Spivak 9y ago
  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.
- jhasse 9y ago
  Not for signed packages, see https://www.reddit.com/r/Fedora/comments/574jmg/potential_bug_installing_without_root/d8p4w1e/ https://www.reddit.com/r/Fedora/comments/574jmg/potential_bu...
  - abrowne 9y ago
    Interesting/weird/scary
Spivak 9y ago
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
- jhasse 9y ago
  > 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_bug_installing_without_root/d8p4w1e/ https://www.reddit.com/r/Fedora/comments/574jmg/potential_bu...
  - yebyen 9y ago
    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!)
    - jhasse 9y ago
      > 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.
      - yebyen 9y ago
        "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?
- lima 9y ago
  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.
- jhasse 9y ago
  > 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.
  - flatpak 9y ago
    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
- pantalaimon 9y ago
  NixOS makes this possible.
  - romwell 9y ago
    The package management model in NixOS looks like what it should have been elsewhere. Do you know why it's not yet the case?

> In particular, how did it come to not being able to install a package without sudo? You can on Fedora via `pkcon install <pkg>`.

by jhasse 9y ago

> In particular, how did it come to not being able to install a package without sudo? You can on Fedora via `pkcon install <pkg>`.

abrowne 9y ago

Won't that just bring up a system (polkit?) password dialog (so no sudo, but you still need an admin password)?

Spivak 9y ago
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.
jhasse 9y ago
Not for signed packages, see https://www.reddit.com/r/Fedora/comments/574jmg/potential_bug_installing_without_root/d8p4w1e/ https://www.reddit.com/r/Fedora/comments/574jmg/potential_bu...
- abrowne 9y ago
  Interesting/weird/scary

Spivak 9y ago

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

jhasse 9y ago
> 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_bug_installing_without_root/d8p4w1e/ https://www.reddit.com/r/Fedora/comments/574jmg/potential_bu...
- yebyen 9y ago
  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!)
  - jhasse 9y ago
    > 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.
    - yebyen 9y ago
      "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?
lima 9y ago
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.
jhasse 9y ago
> 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.
- flatpak 9y ago
  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
pantalaimon 9y ago
NixOS makes this possible.
- romwell 9y ago
  The package management model in NixOS looks like what it should have been elsewhere. Do you know why it's not yet the case?