Re: [pacman-dev] Breaking change in pacman from 5.0.1 -> 5.0.2 with regards to user account resolution
Hello! I have several packages that install files that need to be owned by specific users on the target system. To achieve that I'm using the install command with the -o <username> and -g <group name> flags in the package() function. I'm not using a install script with a post_install() function. Example of the relevant part of the package function package() { install -m 600 -o username -g groupname the_file "$pkgdir"/some/path/to/the_file } The package is built on a build server and then installed on a number of targets. This has worked fine up until I upgraded to 5.0.2 After upgrading pacman to 5.0.2 the file does not get the correct owner on the target system any more. It gets own by the user that has the UID that the user has on the build server which is not the same UID as the user has on the target. To clarify. In my setup the UID of the user is different on the build server compared to the UID of the target system. Before this did not matter. The file got the correct ownership anyway. After 5.0.2 the file gets owned by whatever user account that has the UID and GID that the user has on the build server no matter what UID and GID the user has on the target system. As far as I can tell this is probably the commit that changed the behavior https://git.archlinux.org/pacman.git/commit/?h=release/5.0.x&id=908769b54002e104b90ab2b3e5ca8066affd4394 Temporarily I have changed my PKGBUILD file to specify UID and GID that the target system has instead of the username and groupname on the install command but this seems fragile as it now requires that the UID/GID is the same on all target systems. Both existing and future. Is this an unintended side effect of the commit referenced above, or is this the expected behavior? Best regards, Thomas Karlsson
On 20.06.2017 16:52, Thomas Karlsson wrote:
Hello!
I have several packages that install files that need to be owned by specific users on the target system. To achieve that I'm using the install command with the -o <username> and -g <group name> flags in the package() function. I'm not using a install script with a post_install() function.
Example of the relevant part of the package function
package() { install -m 600 -o username -g groupname the_file "$pkgdir"/some/path/to/the_file }
The package is built on a build server and then installed on a number of targets. This has worked fine up until I upgraded to 5.0.2
After upgrading pacman to 5.0.2 the file does not get the correct owner on the target system any more. It gets own by the user that has the UID that the user has on the build server which is not the same UID as the user has on the target.
To clarify. In my setup the UID of the user is different on the build server compared to the UID of the target system. Before this did not matter. The file got the correct ownership anyway. After 5.0.2 the file gets owned by whatever user account that has the UID and GID that the user has on the build server no matter what UID and GID the user has on the target system.
As far as I can tell this is probably the commit that changed the behavior https://git.archlinux.org/pacman.git/commit/?h=release/5.0.x&id=908769b54002e104b90ab2b3e5ca8066affd4394
Temporarily I have changed my PKGBUILD file to specify UID and GID that the target system has instead of the username and groupname on the install command but this seems fragile as it now requires that the UID/GID is the same on all target systems. Both existing and future.
Is this an unintended side effect of the commit referenced above, or is this the expected behavior?
Best regards, Thomas Karlsson
Hi, if you'd read the messages of that thread referenced in the commit linked in your message, especially that one: https://lists.archlinux.org/pipermail/pacman-dev/2017-March/021922.html , you'd know: Yes, this is expected behavior. -- regards, brainpower
On 06/20/2017 10:52 AM, Thomas Karlsson wrote:
Hello!
I have several packages that install files that need to be owned by specific users on the target system. To achieve that I'm using the install command with the -o <username> and -g <group name> flags in the package() function. I'm not using a install script with a post_install() function.
Example of the relevant part of the package function
package() { install -m 600 -o username -g groupname the_file "$pkgdir"/some/path/to/the_file }
The package is built on a build server and then installed on a number of targets. This has worked fine up until I upgraded to 5.0.2
After upgrading pacman to 5.0.2 the file does not get the correct owner on the target system any more. It gets own by the user that has the UID that the user has on the build server which is not the same UID as the user has on the target.
To clarify. In my setup the UID of the user is different on the build server compared to the UID of the target system. Before this did not matter. The file got the correct ownership anyway. After 5.0.2 the file gets owned by whatever user account that has the UID and GID that the user has on the build server no matter what UID and GID the user has on the target system.
As far as I can tell this is probably the commit that changed the behavior https://git.archlinux.org/pacman.git/commit/?h=release/5.0.x&id=908769b54002e104b90ab2b3e5ca8066affd4394
Temporarily I have changed my PKGBUILD file to specify UID and GID that the target system has instead of the username and groupname on the install command but this seems fragile as it now requires that the UID/GID is the same on all target systems. Both existing and future.
This is eminently reasonable, since it is after all the recommended, proper way to do things. It is also why we have https://wiki.archlinux.org/index.php/DeveloperWiki:UID_/_GID_Database to track standardized UID/GID numbers for packages in the official repos. You can specify the desired UID/GID for a new system user in the sysusers.d(5) snippet that originally created the user.
Is this an unintended side effect of the commit referenced above, or is this the expected behavior?
Seems to me as though your workflow *was* the bug that this commit fixed. :) -- Eli Schwartz
Ok, thanks brainpower and Eli!
This is eminently reasonable, since it is after all the recommended, proper way to do things. It is also why we have >https://wiki.archlinux.org/index.php/DeveloperWiki:UID_/_GID_Database to track standardized UID/GID numbers for packages in the official repos.
You can specify the desired UID/GID for a new system user in the sysusers.d(5) snippet that originally created the user.
Great, thanks for those links! I can see that I was not using the recommended workflow. However, I am still surprised to see such a breaking change to be released in a patch release without it even being mentioned in the release notes/news. Seems a bit harsh to me. From the link given by brainpower I'm apparently not the only one who thinks using the username as key instead of UID is a good (or at least feasible) idea... " This sounds like the expected behavior. The user/group names are
stored in the archive if they exist on the system building the package and bsdtar will use the names rather than the id's by default when extracting the archive."
So, perhaps more people will run into this behavioral change as well. Anyway. I will switch to using UID numbers instead of username now. Thanks, Best regards, Thomas -----Original Message----- From: pacman-dev [mailto:pacman-dev-bounces@archlinux.org] On Behalf Of Eli Schwartz Sent: den 20 juni 2017 23:03 To: pacman-dev@archlinux.org Subject: Re: [pacman-dev] Breaking change in pacman from 5.0.1 -> 5.0.2 with regards to user account resolution On 06/20/2017 10:52 AM, Thomas Karlsson wrote:
Hello!
I have several packages that install files that need to be owned by specific users on the target system. To achieve that I'm using the install command with the -o <username> and -g <group name> flags in the package() function. I'm not using a install script with a post_install() function.
Example of the relevant part of the package function
package() { install -m 600 -o username -g groupname the_file "$pkgdir"/some/path/to/the_file }
The package is built on a build server and then installed on a number of targets. This has worked fine up until I upgraded to 5.0.2
After upgrading pacman to 5.0.2 the file does not get the correct owner on the target system any more. It gets own by the user that has the UID that the user has on the build server which is not the same UID as the user has on the target.
To clarify. In my setup the UID of the user is different on the build server compared to the UID of the target system. Before this did not matter. The file got the correct ownership anyway. After 5.0.2 the file gets owned by whatever user account that has the UID and GID that the user has on the build server no matter what UID and GID the user has on the target system.
As far as I can tell this is probably the commit that changed the behavior https://git.archlinux.org/pacman.git/commit/?h=release/5.0.x&id=908769 b54002e104b90ab2b3e5ca8066affd4394
Temporarily I have changed my PKGBUILD file to specify UID and GID that the target system has instead of the username and groupname on the install command but this seems fragile as it now requires that the UID/GID is the same on all target systems. Both existing and future.
This is eminently reasonable, since it is after all the recommended, proper way to do things. It is also why we have https://wiki.archlinux.org/index.php/DeveloperWiki:UID_/_GID_Database to track standardized UID/GID numbers for packages in the official repos. You can specify the desired UID/GID for a new system user in the sysusers.d(5) snippet that originally created the user.
Is this an unintended side effect of the commit referenced above, or is this the expected behavior?
Seems to me as though your workflow *was* the bug that this commit fixed. :) -- Eli Schwartz
participants (3)
-
brainpower
-
Eli Schwartz
-
Thomas Karlsson