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:

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.

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

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

The Social Box

You can sign up for more updates via Twitter or Facebook below. On Twitter, I regularly talk about technology or tweet about interesting stories. Topics that don't necessarily make it to this blog. Facebook contains a steady update of blogposts and some more lightweight stories.

The @mattiasrss account has an automated RSS feed of all blogposts that get published.

Write a Comment

Do you care about the markup if your comment? You can use the following HTML tags:

<code>command</code>: command highlighting
<pre>text</pre>: pre-formatted code, can be multi-line (black background, white letters)

example <pre> tag
<blockquote>text</blockquote> quoted text
quoted example

None of this is needed of course, it's all optional!



  1. Yes thats right, it should be:

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

    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 :)

  2. 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
      if [ "$1" = "1" ]; then # package is being erased, not upgraded
          /usr/bin/yum remove lftp squid php-gd php-IDNA_Convert

    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.

  3. hi ,
    i have a rpm installed with %postun script and it is affecting upgrade so is there any way to overcome this issue, without affecting old rpm.