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)

  • added by jengelh on 05/18/10 12:33:35.

Change History

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

  • owner changed from RpmTickets to pmatilai.
  • status changed from new to assigned.

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

  • attachment strace.log added.

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

  • attachment ts.spec added.

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

  • status changed from assigned to closed.
  • resolution set to fixed.

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