On 03/02/15 06:05 PM, Allan McRae wrote:

On 03/02/15 22:01, Jerome Leclanche wrote:

...

2015-02-03 12:46 GMT+01:00 Allan McRae :

...

1) We should not remove users/groups when packages are uninstalled. This is a potential security issue if any files are left owned by the non-existent user/group.

When should the cleanup be done? Installing and immediately uninstalling a package should really not do permanent changes to the system; iow, ideally, users shouldn't have to do regular cleanups on their system like that.

Never - what does on extra line in a file matter?

There are a few cases where the user/group isn't actually used for any files, like these ones: https://projects.archlinux.org/svntogit/community.git/tree/trunk/grsec-commo... I wouldn't mind leaving them around, but deleting them isn't really problematic. It's definitely a security issue when it comes to the dynamically assigned range (500..999) since files may be left behind and the user/group could be reused. It doesn't seem like it could be an issue with the reserved static ids though.

On 4 February 2015 at 12:11, Gaetan Bisson wrote:

[2015-02-03 22:10:26 -0500] Daniel Micay:

...

It's definitely a security issue when it comes to the dynamically assigned range (500..999) since files may be left behind and the user/group could be reused. It doesn't seem like it could be an issue with the reserved static ids though.

I concur.

Besides, if we're not going to remove users/groups in post_remove, we might as well ship a default /etc/passwd in the filesystem package with every single user/group in it.

Agreed -- I'd like for static id groups to be removed with the corresponding package. However, that would leave users dangling if they use the group actively for anything beyond the package's domain. One argument there is that they should know the consequences of removing the package associated with the group, but that's not a very strong argument. Either way works for me personally, so +0. -- GPG/PGP ID: C0711BF1

On 02/03/15 at 02:27pm, Evangelos Foutras wrote:

On 03/02/15 13:46, Allan McRae wrote:

...

Hi all,

While looking into how best handle those directory permission warnings with pacman-4.2, I have noticed a couple of things about user/group management in our packages.

1) We should not remove users/groups when packages are uninstalled. This is a potential security issue if any files are left owned by the non-existent user/group.

2) Most packages that chown files in the install file could do it use the user/group number in the PKGBUILD. This works on any package with a reserved user/group ID. The advantage of doing this is that pacman can track the permissions. (A solution is being worked on for dynamically created user/groups whose id number can vary.)

Should I create a rebuild list?

I'd say yes and I agree on both points.

This is also a perfect opportunity to mention systemd-sysusers(8) which, along with sysusers.d(5) entries, can greatly simplify the creation of system users.

For an example, check out the openldap package:

https://projects.archlinux.org/svntogit/packages.git/tree/trunk/slapd.sysuse...

https://projects.archlinux.org/svntogit/packages.git/tree/trunk/openldap.ins...

-1 for systemd-sysusers unless you can figure out a way to use it in pre_install. In order for the dynamic user creation Allan mentioned to work, pacman will have to be changed to use symbolic user names for file ownership which requires the user to exist *before* the package is extracted. apg

On 03/02/2015 17:16, Evangelos Foutras wrote:

On 03/02/15 17:58, Andrew Gregory wrote:

...

-1 for systemd-sysusers unless you can figure out a way to use it in pre_install. In order for the dynamic user creation Allan mentioned to work, pacman will have to be changed to use symbolic user names for file ownership which requires the user to exist *before* the package is extracted.

Yeah, it doesn't seem like systemd-sysusers can be used for that, since the user and group information is stored in a sysusers.d file.

But for packages that use static (reserved) user/group IDs, it should work a treat. :)

Allan, could you clarify your rebuild consign regarding static user/group to move to systemd-sysusers ? Cheers, -- Sébastien "Seblu" Luttringer Archlinux Developer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A