[pacman-dev] Non-existing user/group ownership and chroot
Hi all.
I'm using pacman for my LFS install, and as part of that, I also use hooks used by Arch for, say, systemd-sysusers, systemd-tmpfiles, etc.
Some packages require that certain files/directories are owned by a certain user/group after install. This is somehow hard to achieve with .install file when systemd-sysuser hook is used (see [1] for an example).
Since this is a LFS, it's "bootstrapped" from an already existing linux distro (doesn't have to be arch, it has its own temporary pacman). I use pacman -U -r /path/to/lfs to install packages from the host system.
The issue I'm having is when an user isn't created and chown is ran in PKGBUILD's with statically assigned id's (ie, chown 20:20, where 20 will be an UID for the created user), pacman chowns those files/directories to something else entirely.
I did however notice that on my host (Arch, of course), those missleading uids/gids correspond to the uids/gids of the users that are going to be created in LFS.
So, if I have user/group named:named with uid:gid 20:20, and host system (Arch) has same user:group, with with uid:gid 40:40, the files that I explicitly chowned to 20:20 in PKGBUILD will be chown-ed to 40:40 instead when pacman -U -r ... is ran.
So, how do I solve this problem? I suppose it's an issue in pacman -U with -r option. I can use chown 20:20 in .install file (before the user:groups have been created), and the file will be created with proper ownership.
Thanks in advance.
On 05.03.2017 23:38, Armin K. wrote:
Hi all.
I'm using pacman for my LFS install, and as part of that, I also use hooks used by Arch for, say, systemd-sysusers, systemd-tmpfiles, etc.
Some packages require that certain files/directories are owned by a certain user/group after install. This is somehow hard to achieve with .install file when systemd-sysuser hook is used (see [1] for an example).
Since this is a LFS, it's "bootstrapped" from an already existing linux distro (doesn't have to be arch, it has its own temporary pacman). I use pacman -U -r /path/to/lfs to install packages from the host system.
The issue I'm having is when an user isn't created and chown is ran in PKGBUILD's with statically assigned id's (ie, chown 20:20, where 20 will be an UID for the created user), pacman chowns those files/directories to something else entirely.
I did however notice that on my host (Arch, of course), those missleading uids/gids correspond to the uids/gids of the users that are going to be created in LFS.
So, if I have user/group named:named with uid:gid 20:20, and host system (Arch) has same user:group, with with uid:gid 40:40, the files that I explicitly chowned to 20:20 in PKGBUILD will be chown-ed to 40:40 instead when pacman -U -r ... is ran.
So, how do I solve this problem? I suppose it's an issue in pacman -U with -r option. I can use chown 20:20 in .install file (before the user:groups have been created), and the file will be created with proper ownership.
Thanks in advance.
Oh, and I'm using stock pacman-5.0.1, no additional patches (besides minor makepkg hacks to set CC/CXX and different debug/nondebug CFLAGS/CXXFLAGS).
On 06/03/17 08:40, Armin K. wrote:
On 05.03.2017 23:38, Armin K. wrote:
Hi all.
I'm using pacman for my LFS install, and as part of that, I also use hooks used by Arch for, say, systemd-sysusers, systemd-tmpfiles, etc.
Some packages require that certain files/directories are owned by a certain user/group after install. This is somehow hard to achieve with .install file when systemd-sysuser hook is used (see [1] for an example).
Since this is a LFS, it's "bootstrapped" from an already existing linux distro (doesn't have to be arch, it has its own temporary pacman). I use pacman -U -r /path/to/lfs to install packages from the host system.
The issue I'm having is when an user isn't created and chown is ran in PKGBUILD's with statically assigned id's (ie, chown 20:20, where 20 will be an UID for the created user), pacman chowns those files/directories to something else entirely.
I did however notice that on my host (Arch, of course), those missleading uids/gids correspond to the uids/gids of the users that are going to be created in LFS.
So, if I have user/group named:named with uid:gid 20:20, and host system (Arch) has same user:group, with with uid:gid 40:40, the files that I explicitly chowned to 20:20 in PKGBUILD will be chown-ed to 40:40 instead when pacman -U -r ... is ran.
So, how do I solve this problem? I suppose it's an issue in pacman -U with -r option. I can use chown 20:20 in .install file (before the user:groups have been created), and the file will be created with proper ownership.
Thanks in advance.
Oh, and I'm using stock pacman-5.0.1, no additional patches (besides minor makepkg hacks to set CC/CXX and different debug/nondebug CFLAGS/CXXFLAGS). .
You can either create the groups in the install file and chown the needed files, or have the same group IDs across systems.
A
On 06.03.2017 00:00, Allan McRae wrote:
On 06/03/17 08:40, Armin K. wrote:
On 05.03.2017 23:38, Armin K. wrote:
Hi all.
I'm using pacman for my LFS install, and as part of that, I also use hooks used by Arch for, say, systemd-sysusers, systemd-tmpfiles, etc.
Some packages require that certain files/directories are owned by a certain user/group after install. This is somehow hard to achieve with .install file when systemd-sysuser hook is used (see [1] for an example).
Since this is a LFS, it's "bootstrapped" from an already existing linux distro (doesn't have to be arch, it has its own temporary pacman). I use pacman -U -r /path/to/lfs to install packages from the host system.
The issue I'm having is when an user isn't created and chown is ran in PKGBUILD's with statically assigned id's (ie, chown 20:20, where 20 will be an UID for the created user), pacman chowns those files/directories to something else entirely.
I did however notice that on my host (Arch, of course), those missleading uids/gids correspond to the uids/gids of the users that are going to be created in LFS.
So, if I have user/group named:named with uid:gid 20:20, and host system (Arch) has same user:group, with with uid:gid 40:40, the files that I explicitly chowned to 20:20 in PKGBUILD will be chown-ed to 40:40 instead when pacman -U -r ... is ran.
So, how do I solve this problem? I suppose it's an issue in pacman -U with -r option. I can use chown 20:20 in .install file (before the user:groups have been created), and the file will be created with proper ownership.
Thanks in advance.
Oh, and I'm using stock pacman-5.0.1, no additional patches (besides minor makepkg hacks to set CC/CXX and different debug/nondebug CFLAGS/CXXFLAGS). .
You can either create the groups in the install file and chown the needed files, or have the same group IDs across systems.
A
Entries are alright in .MTREE (correct gid's). I don't suppose pacman does something odd there? Why doesn't it use those uid's/gid's?
If you could point me to the part in the pacman code which does the extraction, I might be able to find a solution (at least for myself).
TA.
On 06/03/17 09:04, Armin K. wrote:
On 06.03.2017 00:00, Allan McRae wrote:
On 06/03/17 08:40, Armin K. wrote:
On 05.03.2017 23:38, Armin K. wrote:
Hi all.
I'm using pacman for my LFS install, and as part of that, I also use hooks used by Arch for, say, systemd-sysusers, systemd-tmpfiles, etc.
Some packages require that certain files/directories are owned by a certain user/group after install. This is somehow hard to achieve with .install file when systemd-sysuser hook is used (see [1] for an example).
Since this is a LFS, it's "bootstrapped" from an already existing linux distro (doesn't have to be arch, it has its own temporary pacman). I use pacman -U -r /path/to/lfs to install packages from the host system.
The issue I'm having is when an user isn't created and chown is ran in PKGBUILD's with statically assigned id's (ie, chown 20:20, where 20 will be an UID for the created user), pacman chowns those files/directories to something else entirely.
I did however notice that on my host (Arch, of course), those missleading uids/gids correspond to the uids/gids of the users that are going to be created in LFS.
So, if I have user/group named:named with uid:gid 20:20, and host system (Arch) has same user:group, with with uid:gid 40:40, the files that I explicitly chowned to 20:20 in PKGBUILD will be chown-ed to 40:40 instead when pacman -U -r ... is ran.
So, how do I solve this problem? I suppose it's an issue in pacman -U with -r option. I can use chown 20:20 in .install file (before the user:groups have been created), and the file will be created with proper ownership.
Thanks in advance.
Oh, and I'm using stock pacman-5.0.1, no additional patches (besides minor makepkg hacks to set CC/CXX and different debug/nondebug CFLAGS/CXXFLAGS). .
You can either create the groups in the install file and chown the needed files, or have the same group IDs across systems.
A
Entries are alright in .MTREE (correct gid's). I don't suppose pacman does something odd there? Why doesn't it use those uid's/gid's?
If you could point me to the part in the pacman code which does the extraction, I might be able to find a solution (at least for myself).
Extraction is just taking files out of the tarball. Note that the tarball store files with UID/GID numbers and not names.
A
On 06.03.2017 00:10, Allan McRae wrote:
On 06/03/17 09:04, Armin K. wrote:
On 06.03.2017 00:00, Allan McRae wrote: Entries are alright in .MTREE (correct gid's). I don't suppose pacman does something odd there? Why doesn't it use those uid's/gid's?
If you could point me to the part in the pacman code which does the extraction, I might be able to find a solution (at least for myself).
Extraction is just taking files out of the tarball. Note that the tarball store files with UID/GID numbers and not names.
A
Oh my. Something else is at play here. Manually extracted tarball contains wrong permissions, .MTREE file reports correct permissions.
pkg/ directory is sadly only owned by the build user. I suppose something between package() and the tarball creation (or just the tarball creation) screws things up. Any ideas what it might be?
libarchive version is 3.3.0. fakeroot is 1.20.1.
On 06.03.2017 00:17, Armin K. wrote:
On 06.03.2017 00:10, Allan McRae wrote:
On 06/03/17 09:04, Armin K. wrote:
On 06.03.2017 00:00, Allan McRae wrote: Entries are alright in .MTREE (correct gid's). I don't suppose pacman does something odd there? Why doesn't it use those uid's/gid's?
If you could point me to the part in the pacman code which does the extraction, I might be able to find a solution (at least for myself).
Extraction is just taking files out of the tarball. Note that the tarball store files with UID/GID numbers and not names.
A
Oh my. Something else is at play here. Manually extracted tarball contains wrong permissions, .MTREE file reports correct permissions.
pkg/ directory is sadly only owned by the build user. I suppose something between package() and the tarball creation (or just the tarball creation) screws things up. Any ideas what it might be?
libarchive version is 3.3.0. fakeroot is 1.20.1.
This is indeed libarchive/bsdtar problem. The permissions are just fine when extracted in chroot, but not when extracted from outside of it.
Looks like behaviour changed, and that tarball stores uid/gid isn't true (anymore). Directory owned by a certain user is owned by the same user in and outside of chroot, besides two of them having different uids/gids.
On 03/06/17 at 10:12am, Armin K. wrote:
On 06.03.2017 00:17, Armin K. wrote:
On 06.03.2017 00:10, Allan McRae wrote:
On 06/03/17 09:04, Armin K. wrote:
On 06.03.2017 00:00, Allan McRae wrote: Entries are alright in .MTREE (correct gid's). I don't suppose pacman does something odd there? Why doesn't it use those uid's/gid's?
If you could point me to the part in the pacman code which does the extraction, I might be able to find a solution (at least for myself).
Extraction is just taking files out of the tarball. Note that the tarball store files with UID/GID numbers and not names.
A
Oh my. Something else is at play here. Manually extracted tarball contains wrong permissions, .MTREE file reports correct permissions.
pkg/ directory is sadly only owned by the build user. I suppose something between package() and the tarball creation (or just the tarball creation) screws things up. Any ideas what it might be?
libarchive version is 3.3.0. fakeroot is 1.20.1.
This is indeed libarchive/bsdtar problem. The permissions are just fine when extracted in chroot, but not when extracted from outside of it.
Looks like behaviour changed, and that tarball stores uid/gid isn't true (anymore). Directory owned by a certain user is owned by the same user in and outside of chroot, besides two of them having different uids/gids.
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.
apg
On 06.03.2017 14:45, Andrew Gregory wrote:
On 03/06/17 at 10:12am, Armin K. wrote:
On 06.03.2017 00:17, Armin K. wrote:
On 06.03.2017 00:10, Allan McRae wrote:
On 06/03/17 09:04, Armin K. wrote:
On 06.03.2017 00:00, Allan McRae wrote: Entries are alright in .MTREE (correct gid's). I don't suppose pacman does something odd there? Why doesn't it use those uid's/gid's?
If you could point me to the part in the pacman code which does the extraction, I might be able to find a solution (at least for myself).
Extraction is just taking files out of the tarball. Note that the tarball store files with UID/GID numbers and not names.
A
Oh my. Something else is at play here. Manually extracted tarball contains wrong permissions, .MTREE file reports correct permissions.
pkg/ directory is sadly only owned by the build user. I suppose something between package() and the tarball creation (or just the tarball creation) screws things up. Any ideas what it might be?
libarchive version is 3.3.0. fakeroot is 1.20.1.
This is indeed libarchive/bsdtar problem. The permissions are just fine when extracted in chroot, but not when extracted from outside of it.
Looks like behaviour changed, and that tarball stores uid/gid isn't true (anymore). Directory owned by a certain user is owned by the same user in and outside of chroot, besides two of them having different uids/gids.
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.
apg
I've contacted libarchive devs and they suggested --numeric-owner bsdtar option. It works just as I expect it to.
On 03/06/17 at 05:40pm, Armin K. wrote:
On 06.03.2017 14:45, Andrew Gregory wrote:
On 03/06/17 at 10:12am, Armin K. wrote:
On 06.03.2017 00:17, Armin K. wrote:
On 06.03.2017 00:10, Allan McRae wrote:
On 06/03/17 09:04, Armin K. wrote:
On 06.03.2017 00:00, Allan McRae wrote: Entries are alright in .MTREE (correct gid's). I don't suppose pacman does something odd there? Why doesn't it use those uid's/gid's?
If you could point me to the part in the pacman code which does the extraction, I might be able to find a solution (at least for myself).
Extraction is just taking files out of the tarball. Note that the tarball store files with UID/GID numbers and not names.
A
Oh my. Something else is at play here. Manually extracted tarball contains wrong permissions, .MTREE file reports correct permissions.
pkg/ directory is sadly only owned by the build user. I suppose something between package() and the tarball creation (or just the tarball creation) screws things up. Any ideas what it might be?
libarchive version is 3.3.0. fakeroot is 1.20.1.
This is indeed libarchive/bsdtar problem. The permissions are just fine when extracted in chroot, but not when extracted from outside of it.
Looks like behaviour changed, and that tarball stores uid/gid isn't true (anymore). Directory owned by a certain user is owned by the same user in and outside of chroot, besides two of them having different uids/gids.
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.
apg
I've contacted libarchive devs and they suggested --numeric-owner bsdtar option. It works just as I expect it to.
pacman already only uses the numeric id's during extraction.
On 06.03.2017 17:48, Andrew Gregory wrote:
On 03/06/17 at 05:40pm, Armin K. wrote:
On 06.03.2017 14:45, Andrew Gregory wrote:
On 03/06/17 at 10:12am, Armin K. wrote:
On 06.03.2017 00:17, Armin K. wrote:
On 06.03.2017 00:10, Allan McRae wrote:
On 06/03/17 09:04, Armin K. wrote: > On 06.03.2017 00:00, Allan McRae wrote: > Entries are alright in .MTREE (correct gid's). I don't suppose pacman > does something odd there? Why doesn't it use those uid's/gid's? > > If you could point me to the part in the pacman code which does the > extraction, I might be able to find a solution (at least for myself). >
Extraction is just taking files out of the tarball. Note that the tarball store files with UID/GID numbers and not names.
A
Oh my. Something else is at play here. Manually extracted tarball contains wrong permissions, .MTREE file reports correct permissions.
pkg/ directory is sadly only owned by the build user. I suppose something between package() and the tarball creation (or just the tarball creation) screws things up. Any ideas what it might be?
libarchive version is 3.3.0. fakeroot is 1.20.1.
This is indeed libarchive/bsdtar problem. The permissions are just fine when extracted in chroot, but not when extracted from outside of it.
Looks like behaviour changed, and that tarball stores uid/gid isn't true (anymore). Directory owned by a certain user is owned by the same user in and outside of chroot, besides two of them having different uids/gids.
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.
apg
I've contacted libarchive devs and they suggested --numeric-owner bsdtar option. It works just as I expect it to.
pacman already only uses the numeric id's during extraction.
It might be libarchive bug/feature. I've found archive_write_disk_set_standard_lookup() which will force resolving uid/gid's if used. The trick is, version 3.3.0 I compiled packman against, calls such function almost uncoditionally in archive_read_extract().
https://github.com/libarchive/libarchive/blob/master/libarchive/archive_read...
On 03/06/17 at 06:06pm, Armin K. wrote:
On 06.03.2017 17:48, Andrew Gregory wrote:
On 03/06/17 at 05:40pm, Armin K. wrote:
...
I've contacted libarchive devs and they suggested --numeric-owner bsdtar option. It works just as I expect it to.
pacman already only uses the numeric id's during extraction.
It might be libarchive bug/feature. I've found archive_write_disk_set_standard_lookup() which will force resolving uid/gid's if used. The trick is, version 3.3.0 I compiled packman against, calls such function almost uncoditionally in archive_read_extract().
https://github.com/libarchive/libarchive/blob/master/libarchive/archive_read...
Aha, how nice of them. Things like this are why I don't recommend using --root to manage chroot's. I suppose I need to get around to finishing alpm's user handling.
apg
On 06.03.2017 18:25, Andrew Gregory wrote:
On 03/06/17 at 06:06pm, Armin K. wrote:
On 06.03.2017 17:48, Andrew Gregory wrote:
On 03/06/17 at 05:40pm, Armin K. wrote:
...
I've contacted libarchive devs and they suggested --numeric-owner bsdtar option. It works just as I expect it to.
pacman already only uses the numeric id's during extraction.
It might be libarchive bug/feature. I've found archive_write_disk_set_standard_lookup() which will force resolving uid/gid's if used. The trick is, version 3.3.0 I compiled packman against, calls such function almost uncoditionally in archive_read_extract().
https://github.com/libarchive/libarchive/blob/master/libarchive/archive_read...
Aha, how nice of them. Things like this are why I don't recommend using --root to manage chroot's. I suppose I need to get around to finishing alpm's user handling.
apg
A potential solution would be to port pacman to archive_read_extract2(), which archive_read_extract() currently wraps.
I'll wait and see what's the libarchive upstream thought on this.
participants (3)
-
Allan McRae
-
Andrew Gregory
-
Armin K.