[arch-dev-public] user/group management in packages
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? Cheers, Allan
2015-02-03 12:46 GMT+01:00 Allan McRae <allan@archlinux.org>:
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. J. Leclanche
On 03/02/15 22:01, Jerome Leclanche wrote:
2015-02-03 12:46 GMT+01:00 Allan McRae <allan@archlinux.org>:
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?
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 <allan@archlinux.org>:
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.
[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. There's also the issue of packages like postfix that use an upstream script to set permissions right after the package is installed. Well... I'll wait to see all this issues addressed before looking at the new todo list. Cheers. -- Gaetan
On 4 February 2015 at 12:11, Gaetan Bisson <bisson@archlinux.org> 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 05/02/15 23:05, Rashif Ray Rahman wrote:
On 4 February 2015 at 12:11, Gaetan Bisson <bisson@archlinux.org> 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.
There is no good argument for removing any user/group IDs. Potentially leaving files that are owned by a non-existent user/group is still an issue, even if these are static IDs that can "never" be used by anything else. A
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...
On Tue, Feb 3, 2015 at 1:27 PM, Evangelos Foutras <evangelos@foutrelis.com> wrote:
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.
+1 for doing this. -- Andrea
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/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. :)
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
On 04/02/15 13:21, Sébastien Luttringer wrote:
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 ?
I don't care...
participants (9)
-
Allan McRae
-
Andrea Scarpino
-
Andrew Gregory
-
Daniel Micay
-
Evangelos Foutras
-
Gaetan Bisson
-
Jerome Leclanche
-
Rashif Ray Rahman
-
Sébastien Luttringer