Is it possible to allow non-root users to install packages system-wide using apt or rpm?

The place where I work currently has an out of date setup on the linux boxes, and admins are sick of having to do all the installations for users on request, so they are thinking of giving full sudo rights to all users. This has obvious security disadvantages. So I'm wondering if there's a way to allow normal users to install software - and to upgrade and remove it?

  • 5
    If you give privileges to install packages, you have essentially given full admin rights, since a user could just install a package with a setuid-root shell.
    – camh
    May 29, 2012 at 10:51
  • @camh hrm.. you could have a vetted repository, and not let users add new repositories, no? Or does apt allow you to install packages from .deb files? I realise a vetted repo would probably be more work in the long-run, this is more of a conceptual question :)
    – naught101
    May 29, 2012 at 13:25
  • 1
    apt-secure(8) says: "apt-get will currently only warn for unsigned archives, future releases might force all sources to be verified before downloading packages from them". Depending on how sophisticated an attack is, it could be possible to hijack the connection to the repository source and inject an untrusted package. However, read that man page for more details. You may have a secure enough solution for your thread model.
    – camh
    May 29, 2012 at 15:21
  • 2
    Related: Non-Root Package Managers Feb 26, 2013 at 20:22
  • 1

5 Answers 5


You can specify the allowed commands with sudo; you don't have to allow unlimited access, e.g.,

username ALL = NOPASSWD : /usr/bin/apt-get , /usr/bin/aptitude

This would allow username to run sudo apt-get and sudo aptitude without any password, but would not allow any other commands.

You can also use PackageKit combined with polkit for some finer level of control than sudo.

Allowing users to install/remove packages can be a risk.  They can pretty easily render a system nonfunctional just by uninstalling necessary software, like libc6, dpkg, rpm etc.  Installing arbitrary software from the defined archives may allow attackers to install outdated or exploitable software and gain root access.  The main question in my opinion is how much do you trust your employees?

Of course your admin team could also start using a configuration management system like puppet, chef or look into spacewalk to manage your system. This would allow them to configure and manage the system from a central system.

  • I left it out of my question, but do you have any comments on the security reduction implied by allowing this? I mean, you can't change the package repositories, so you're probably not going to get full sudo access, but you can write to any file using aptitude (options > preferences > "File to log actions into"), which could cause some serious damage. I'm less certain about PolicyKit...
    – naught101
    May 29, 2012 at 4:41
  • 1
    @naught101 ok i added some comments about security. JFTR as policykit won't provide root access it would be less problematic than using sudo May 29, 2012 at 10:31
  • There are ways that you can run a shell from dpkg or rpm. For example: dpkg will prompt when there is a config file change which clashes, with one of the options being start a shell to examine the situation. This will start a shell as root if run via sudo. Likewise if you can run an editor from the tool, as most editors let you run arbitrary shell commands from within them (e.g. !command in vi). Sep 22, 2016 at 13:01
  • @naught101 I would test for privilege escalation via a RPM that contains a SUID shell as this blog describes: nosedookie.blogspot.com/2011/07/… In a shell injection scenario, however, where the sudoer account is compromised, one could mitigate privilege escalation via sudo by requiring a password to be entered, as opposed to NOPASSWD.
    – Matt Borja
    Oct 19, 2016 at 16:07
  • 1
    I do not understand this answer. I provides a line that we are supposed to write ... where ???
    – Vince
    Nov 16, 2021 at 11:12


From the man pages:

aptdcon: allows to perform package management tasks, e.g. installing or removing software, using aptdaemon. There isn't any need to be root to run this program.

  • 1
    Although you do not need root/sudo privileges to run aptdcon, it immediately launches an authentication dialog for unprivileged users - I just tested on Ubuntu. If you are not a privileged/authorized user, then this does not add/remove packages.
    – sage
    Aug 31, 2016 at 1:21
  • 1
    Doesn't work on operations ERROR: You are not allowed to perform this action. ('system-bus-name', {'name': ':1.716'}): org.debian.apt.install-or-remove-packages
    – JacopKane
    Jan 16, 2019 at 21:51
  • I have tried adding [Install software] Identity=unix-group:admin;unix-group:sudo;unix-group:fic Action=org.debian.apt.install-or-remove-packages ResultActive=yes to /var/lib/polkit-1/localauthority/10-vendor.d/com.ubuntu.desktop.pkla but it does not work as expected
    – rapto
    Oct 20, 2020 at 18:27
username ALL = NOPASSWD : /usr/bin/yum, /bin/rpm

For me on the Debian 10 the option with visodo required additional steps:

  1. Add yourself to the sudousers:

Login as root via su -, open sudo editor by visudo and add next lines:

%yourusername% ALL=NOPASSWD: /usr/bin/apt-get install
%yourusername% ALL=NOPASSWD: /var/lib/dpkg/lock-frontend
  1. Exit session(root and yours) typing exit <Enter> exit <\Enter>

  2. Reopen it and type:

     sudo chown  %yourusername%: /var/lib/dpkg/lock-frontend
     chmod  u+w /var/lib/dpkg/lock-frontend 
     sudo chown  %yourusername%: /var/lib/dpkg/lock
     chmod  u+w /var/lib/dpkg/lock
     sudo chown  %yourusername%: /var/cache/apt/archives/lock
     chmod  u+w /var/cache/apt/archives/lock
     sudo chown  %yourusername%:  /var/lib/apt/lists/lock
     chmod  u+w  /var/lib/apt/lists/lock

PS: I also added the visudo file lines to allow myself to update repos list:

%yourusername% ALL=NOPASSWD: /usr/bin/apt-get update
  • Why are you wrapping a variable in % signs? % means something in that file which adds a point of confusion. In step three, if you renamed it to $(whoami), it wouldn't have to be edited. That said, this did fix the problem for me, so I appreciate you posting it. Feb 2, 2022 at 6:54

I also looked for something like that, but nothing showed up, so I coded this easy solution "softwarechannels":


It is a very simple system to allow common (no admin) users to install packages from restricted catalogs.

Just define 'channels' (groups of packages) in a simple text file and give your users permissions to launch softwarechannels.

They will only see packages in channels matching their unix groups.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .