urpmi fails to run via sudo if the current directory is not readable by root: Assume you are logged in as a normal (non-root) user. The user's home is on a nfs-share, where root doe not even have read-permissions. $ cd $HOME $ LC_ALL=C sudo urpmi --auto-update [...] installing lib64ldap2.4_2-2.4.33-7.1.mga3.x86_64.rpm [...] error: Unable to open current directory: Permission denied Now try again in /tmp (where root has read permissions) $ cd /tmp $ LC_ALL=C sudo urpmi --auto-update [...] installing lib64ldap2.4_2-2.4.33-7.1.mga3.x86_64.rpm [...] Preparing... ############################################## [... okay ...] Please note: This most probably only occurs if the current working directory is on a NFS-share with root-sqash. On a local directory, root can still read the directory, even if permissions are not granted: /home is nfs-share: $ mkdir -p /tmp/a/b/c $ chmod o= /tmp/a /tmp/a/b $ ls -l /tmp/a/b insgesamt 0 drwxr-xr-x 2 johndoe johndoe 40 Feb 17 09:45 c/ $ su - # LC_ALL=C ls -l /home/johndoe ls: cannot open directory /home/johndoe: Permission denied # ls -l /tmp/a/b total 0 drwxr-xr-x 2 johndoe johndoe 40 Feb 17 09:45 c/
Source RPM: (none) => urpmi-7.27.3-2.mga3
My analysis seams to be wrong: I ran sudo urpmi --auto-update on a different directory which is on the same nfs-share and it worked. In this directory, the command failed: $ getfacl ~ # file: home/johndoe # owner: johndoe # group: johndoe user::rwx user:501:rwx #effective:--x [[501 is a obsolete user id]] group::r-x #effective:--x mask::--x other::--x In this directory, the command worked: $ getfacl ~/Downloads/ # file: home/johndoe/Downloads/ # owner: johndoe # group: johndoe user::rwx group::r-x other::r-x So differences in ~/Downloads are: - no mask defined - "others" have read permissions. Please give me hints how I can help debugging this.
You cannot. The NFS server simply denies access to root according to file permissions. You could either not call "sudo urpmi" from such a directory or alter your permissions, but it's much simpler to use "sudo -i urpmi". See sudo man page.
Status: NEW => RESOLVEDCC: (none) => thierry.vignaudResolution: (none) => INVALID
Thierry, why at all does urpmi *require* access to the current directory? This, IMHO, is the bug.
Status: RESOLVED => REOPENEDResolution: INVALID => (none)
It doesn't. librpm does. (lib/rpmchroot.c) It needs to keep an open file descriptor on the current working directory in order to go out of the chroot in case it needs to chroot.
Status: REOPENED => RESOLVEDResolution: (none) => INVALID
JFTR: This only fails if the current directory is on a nfs-share with root_sqash. On a local directory, root can always read.
This still fails on Mageia 5. Proposed solution: Just before starting urpm::main_loop::run, chdir to some directory root is able to write to, e.g. /tmp. I tested this and this solves the problem. Patch attached. You may wan to choose some other directory, e.g $HOME (wich need to be root's home, tough).
Status: RESOLVED => REOPENEDVersion: 3 => 5Resolution: INVALID => (none)Source RPM: urpmi-7.27.3-2.mga3 => urpmi-8.06-1.mga5.src.rpm
Created attachment 7218 [details] proposed patch: chdir befroe starting urpm::main_loop::run
Keywords: (none) => PATCH
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=17202
Status comment: (none) => workaround available, need to decide if will be implemented in urpmiAssignee: bugsquad => mageiatools
Version: 5 => CauldronWhiteboard: (none) => MGA5TOO
Comment on attachment 7218 [details] proposed patch: chdir befroe starting urpm::main_loop::run We'd rather chdir() to "/" rather than "/tmp", it's guaranteed to exist