Re: Breaking change in pacman from 5.0.1 -> 5.0.2 with regards to user account resolution

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Breaking change in pacman from 5.0.1 -> 5.0.2 with regards to user account resolution

Thomas Karlsson
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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Breaking change in pacman from 5.0.1 -> 5.0.2 with regards to user account resolution

brainpower
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


signature.asc (883 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Breaking change in pacman from 5.0.1 -> 5.0.2 with regards to user account resolution

Eli Schwartz
In reply to this post by Thomas Karlsson
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


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Breaking change in pacman from 5.0.1 -> 5.0.2 with regards to user account resolution

Thomas Karlsson
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:[hidden email]] On Behalf Of Eli Schwartz
Sent: den 20 juni 2017 23:03
To: [hidden email]
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

Loading...