On removing users with %postun in RPM SPEC files

The moment you start to write your own SPEC files for creating RPM images, you may be tempted to do the following in the %postun section of the file:

%postun
userdel --force daemonuser 2> /dev/null; true

It seems only logical: in the uninstall section of the RPM package, delete the user that was once used for that package. After all, why would the user be left behind when you uninstall or remove a package?

My advice would be: don't do this. While the logic makes sense, it poses a few problems.

It breaks upgrades

If you install a new version of your RPM package via yum or manually via "rpm -Uvh", the %postun is triggered. Why? Because when upgrading what actually happens is your package manager will install the new RPM package and then remove the previous version, thus triggering the %postun. Since the delete of the previous version happens last, with the configuration above the user running your application is removed from the system.

It poses a security threat

Assuming you've added users in your SPEC file to manage your application, it could pose a security leak when removing that user in the %postun section. After all, if afterwards a new user is created and it is given the UID of that deleted user, it has full access to the configuration or log files that may be left behind and are only readable by that user.

Granted, chances are slim, but your user can add sensitive configuration files that your RPM file knows nothing about.

Still need it? Check the $1 variable

If you still want to delete a user upon uninstall of your RPM but not when upgrading, you can evaluate the $1 variable in %postun. If that first argument is 1, the action is an upgrade. If it's 0, it's a removal of your package. Hence, the code snippet from above should be changed to the following.

%postun
if [ "$1" = "1" ]; then
   userdel --force daemonuser 2> /dev/null; true
fi

If you have any other comments on %postun and users I'd love to hear them.

4 comments on “On removing users with %postun in RPM SPEC files
  1. Asif says:

    shouldn’t it be $1 == 0 as you are confining it to a rpm erase not update?

  2. Oleg says:

    Yes thats right, it should be:

    if [ "$1" == 0 ]; then
       userdel --force daemonuser 2> /dev/null; true
    fi
    

    because you want to delete an User only if you uninstall the package and do not update it.

    Hence the Code from Matthias does exactly the thing he wanted to avoid :)

  3. Momin says:

    I am uninstalling rpm while i want to remove it dependencies rpm also which i also install through rpm.

    Requires: lftp, squid, php-gd, php-IDNA_Convert
    
    %postun
      if [ "$1" = "1" ]; then # package is being erased, not upgraded
          /usr/bin/yum remove lftp squid php-gd php-IDNA_Convert
      fi
    

    Now when i am remove main rpm, its only remove the one rpm not deleting dependent rpm, how i can achieve that?

    • For starters, it won’t show up in the dependency-tree when you “yum remove $package“.

      I’m sure this is terrible best practice, but you could try “yum -y remove $packagelist“, after all – yum by default requests confirmation.

      The RPM SPEC isn’t that clear to me, but if my memory serves me correctly, you can use the “Obsoletes: $packagelist for dependency removal. Same syntax as Requires:, just a different keyword.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Advertisement

Why ads?

I'm glad you made it to this blogpost. I hope it helps solve your problem. So why then do I show ads on the site? Writing content, testing it and making sure the layout isn't totally b0rked takes time. A lot of time. The ads are a way to pay back a small portion of that time.

And as you know running a site costs (a bit of) money: the domain name, webhosting, time spent writing and updating content, ... So if you like the content of this blog, consider disabling your AdBlocker for this domain. Thanks!

Looking for help?

Tired of fixing all these tech-problems yourself? We've got an excellent team at Nucleus, a top-class Belgian hosting provider, that can help you.

Discover our Managed Hosting, where skilled engineers manage your servers and keep them up-to-date, so you can focus on your core business. We use a variety of Configuration Management Systems such as Puppet to make sure every config is reviewed, unit-tested and guaranteed to be working.

Want to get in touch? Find me as @mattiasgeniar on Twitter or via the contact-page on this blog.