Hide Forgot
Created attachment 475199 [details] rpm -Fvvvh output Attempting to install an rpm when the current directory happens to be my nfs4-mounted home directory that is not executable by root will fail silently. This happens even though the package itself is readable, or even if I move the package to a path where root has complete access. This causes rather bizarre yum failures as the transaction just silently aborts and yum has no idea why. I've attached the output of a -vvv run of rpm. The current directory is my home; you can see that rpm has no trouble opening the actual package and computing checksums, but it fails to actually do anything. Basic rpm query operations still work fine, so I can do: > sudo rpm -q rpm rpm-4.9.0-0.beta1.3.fc15.x86_64 (though obviously I don't need to run that as root).
Can you easily check does the same thing happen with rpm 4.8.x (ie is this a regression or an older bug)?
Also if you can attach a strace of the operation that'd be helpful (might save me having to setup nfs environment for testing this)
This does not happen on F14; I only noticed it happening on rawhide recently. Since I don't generally use rpm directly, I thought this was a yum problem and spent a while trying to track it down that way. However, I'm pretty sure it started when 4.9.0 hit rawhide. Just as additional info, rpm -e has the same behavior, and turning off selinux has no effect. I'll attach strace output from trying to install a package. There is one point where it does: 14090 open(".", O_RDONLY) = -1 EACCES (Permission denied) and at that point it seems to close everything and exit.
Created attachment 475410 [details] Output of sudo strace -f -o /tmp/a rpm -i xu4*
Thanks, I'll look into it.
Okay, this really just needs an error message. Rpm needs readable cwd for reliable cwd restoration after returning from chroot and lua scriptlets (rpm 4.8.x is buggy here). Chroot is not used here in this case, but rpm doesn't know at the start of the the transaction whether it will be running lua scriptlets or not (they could be triggers from other packages which isn't known until much later). So instead of failing with mysterious scriptlet errors in middle of transaction in some situations, it's better to bail out + complain early if open(".") fails.
Should be fixed in rpm-4.9.0-0.beta1.5.fc15 in the sense that you'll now get an error message on non-readable current directory instead of silent abort.
Panu, why do you need this ... isn't it better to just chdir("/") if open(".") fails? My main worry here is that there will be a non-trivial number of people with NFS homedirs (with rootsquash, etc.), who will now get errors when they run yum commands.
Doing chdir("/") breaks at least non-absolute paths to packages in turn (think of 'rpm -Uvh foo.rpm', 'yum localinstall foo.rpm'), unless callers (/bin/rpm included) are updated to always use absolute paths. And yes the current behavior is fairly draconian, but the alternatives aren't that nice either.
Yeh, I tried to think of something we could do at the yum layer which would work around this ... and we might, but it'd be a lot of work to make it 100%. What I meant was that for 99.999% of people open(".") is going to work, so you could just do the chdir() then ... which might be better than just failing. I did the obvious: http://james.fedorapeople.org/yum/plugins/chdir.py http://james.fedorapeople.org/yum/plugins/chdir.conf ...but Jason would prefer to just alias yum to "cd /tmp; yum" so I'm not sure how useful that is.
I just wanted to add a comment that I found things to work quite fine on F16 release. There's no error message; things just work as they used do pre-4.9. I haven't been tracking rawhide closely so I don't know when things were changed or just what went on under the hood but it's quite nice to have the old behavior back.
We worked around it in yum: http://yum.baseurl.org/gitweb?p=yum.git;a=commitdiff;h=d54a93855018030d98286c8eff8526f83cde5b97 ...might be worth porting to RHEL-6, can you open a bug Jason?
Oh, awesome, thanks. I don't use RHEL6 so I'm not sure if there is something specific I'd need to do.