[arch-general] Fix or not fix? install scriptlets with user handling.

RedShift redshift at pandora.be
Thu May 28 05:28:30 EDT 2009


Gerardo Exequiel Pozzi wrote:
> Hi,
> 
> Many package manage user/groups in many differents ways. (no much
> problem here)
> 
> Many do things like:
> 
> @ when installed
> 1) check if not user foo exists then create it
> 2) check if not group foo exists then create it
> @when removed
> 1) remove the user foo (without check)
> 2) remove the group foo (without check)
> 
> Because by default the option USERGROUPS_ENAB is set to yes, when user
> "foo" is removed also the group "foo" is removed, so the groupdel
> command will fail, then pacman show the message: "error: scriptlet
> failed to execute correctly".
> 
> The solution is trivial, check with getent before remove, just like some
> packages do it before create the user.
> 
> My question here, is there interest in resolving this? Currently I have
> the choice of those who fail (both extra and comunity). Do you send a
> report to everyone who fail to flyspray with the patch (low priority)?
> Also I can unify the user creation step, some .install check with "grep"
> and others with "getent". I prefer the proper getent method.
> 
> The only package in [core] that have this issue is dbus-core [#1] and is
> actually reported.
> 
> 
> [#1] http://bugs.archlinux.org/task/14810
> 

Hi


IMNSHO .install scripts should never ever add users or groups, let alone remove them. Everything that would need a user for itself should default to "nobody". Yes, this imposes, though small, a security risk but any decent server admin will move that stuff to its own user.

I've even seen packages that start and stop daemons themselves (shrug!), if it were up to me there would be no such things. But many believe that automatically adding and removing users is "OK". A package should install its program files, and THAT'S IT. Nothing more. It may be a bit a spartan way, but it's reliable (no unexpected surprises) and leads to an uncluttered passwd and group file.


Glenn


More information about the arch-general mailing list