You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Debian package ossec-hids-server_3.6.0-12034buster_amd64.deb contains a postrm script that removes the ossec users on groups on upgrades. It should not do this. Suggest: in postrm change
case "$1" in
purge|remove|upgrade|failed-upgrade|abort-install|abort-upgrade|disappear)
to
case "$1" in
purge|remove|failed-upgrade|abort-install|abort-upgrade|disappear)
Here is the situation where removing and re-adding ossec user/group on upgrade causes problems: you manage service accounts (such as ossec, ossecr, ossecm) using a configuration management system such as Puppet or Ansible.
Let's assume that you manage user "ossec" with Puppet and Puppet ensures that user "ossec" has uid 520. Before the ossec server upgrade the installed ossec system files are owned by user "ossec". This really means they are owned by the user with uid 520.
You upgrade ossec. As mentioned above this deletes user "ossec" and re-adds it. This means user "ossec" now has a NEW uid, say 116. As part of the upgrade the package changes the ownership of the ossec system files to user "ossec". But now that means that the files are owned by the user with uid 116.
You do a Puppet run. This CHANGES the uid of "ossec" back to 520.
The ossec service runs as user "ossec", so the next time it restarts it runs as user with uid 520. But the ossec systems files are owned by the user with uid 116. Thus the ossec service fails.
The Debian package ossec-hids-server_3.6.0-12034buster_amd64.deb contains a postrm script that removes the ossec users on groups on upgrades. It should not do this. Suggest: in postrm change
to
Here is the situation where removing and re-adding ossec user/group on upgrade causes problems: you manage service accounts (such as ossec, ossecr, ossecm) using a configuration management system such as Puppet or Ansible.
Let's assume that you manage user "ossec" with Puppet and Puppet ensures that user "ossec" has uid 520. Before the ossec server upgrade the installed ossec system files are owned by user "ossec". This really means they are owned by the user with uid 520.
You upgrade ossec. As mentioned above this deletes user "ossec" and re-adds it. This means user "ossec" now has a NEW uid, say 116. As part of the upgrade the package changes the ownership of the ossec system files to user "ossec". But now that means that the files are owned by the user with uid 116.
You do a Puppet run. This CHANGES the uid of "ossec" back to 520.
The ossec service runs as user "ossec", so the next time it restarts it runs as user with uid 520. But the ossec systems files are owned by the user with uid 116. Thus the ossec service fails.
See also https://unix.stackexchange.com/questions/47880/how-debian-package-should-create-user-accounts
The text was updated successfully, but these errors were encountered: