Ticket #157 (closed defect: fixed)

Opened 5 years ago

Last modified 2 years ago

Permissions not attached to files in chroots


Reported by: jengelh Assigned to: pmatilai Priority: major Milestone:
Component: rpm Version: RPM Development Keywords: Cc:


Description

Installation with rpm --root yields:

/srv/nfs/base32# linux32 rpm --root $PWD -Uhv cups-client-1.3.11-4.5.1.i586.rpm Preparing... ########################################### [100%]

1:cups-client warning: user lp does not exist - using root( 26%)

warning: group lp does not exist - using root ########################################### [100%]

And that despite lp existing in both /etc/{passwd,group} and /srv/nfs/base32/etc/{passwd,group}. Looks non-trivial. Any idea what could be done?

Attachments

strace.log (139.0 kB) - added by jengelh on 05/18/10 12:33:21.

ts.spec (173 bytes)

Change History

05/17/10 11:51:09 changed by pmatilai

Basically that means getpwnam() is failing for whatever reason. Rpm (tries to) preload nss libraries before chroot() to ensure working name services inside chroots but maybe there's a new catch here or something...

Try to get a strace log of the thing, that should provide some clues to what's going on.

05/18/10 12:32:34 changed by jengelh

It is reproducible using one's own system root itself, i.e.

rpm --root / -Uhv ts.rpm

05/18/10 12:33:21 changed by jengelh

05/18/10 12:33:35 changed by jengelh

05/19/10 13:04:51 changed by pmatilai

FWIW I can't reproduce this. ts.spec does complain about user sys not existing but rightfully so as on Fedora there's no such user (only group called "sys"), and using other user/group names doesn't change the situation. Need to dig into the strace...

05/19/10 13:24:11 changed by pmatilai

Looking at the strace log, this has to do with the host being configured to use LDAP for user information and the system not falling back to /etc/{passwd,group} when not found in LDAP.

01/28/14 12:30:49 changed by pmatilai

This is likely to be the same issue as the one reported here: http://lists.rpm.org/pipermail/rpm-maint/2014-January/003652.html and should be fixed by this: https://rpm.org/gitweb?p=rpm.git;a=commitdiff;h=abbf4897db217b4977b4c21eb09929c797ee015d