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.