Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Debian package postinst should not remove ossec users on upgrade #1970

Open
macrotex opened this issue May 9, 2021 · 0 comments
Open

Debian package postinst should not remove ossec users on upgrade #1970

macrotex opened this issue May 9, 2021 · 0 comments

Comments

@macrotex
Copy link

macrotex commented May 9, 2021

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.

  1. 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.

  2. 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.

  3. You do a Puppet run. This CHANGES the uid of "ossec" back to 520.

  4. 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

atomicturtle added a commit to atomicturtle/ossec-hids that referenced this issue Jun 1, 2021
Signed-off-by: Scott R. Shinn <scott@atomicorp.com>
ddpbsd added a commit that referenced this issue Jun 1, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant