Bug 912448 - sudo only works first time it is run (/usr/bin is on NFS)
Summary: sudo only works first time it is run (/usr/bin is on NFS)
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 17
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-02-18 17:05 UTC by Göran Uddeborg
Modified: 2013-02-18 17:33 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2013-02-18 17:33:01 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
"strace -f" of bash when running "sudo id" twice (112.23 KB, application/octet-stream)
2013-02-18 17:05 UTC, Göran Uddeborg
no flags Details

Description Göran Uddeborg 2013-02-18 17:05:31 UTC
Created attachment 699002 [details]
"strace -f" of bash when running "sudo id" twice

Description of problem:
I have a diskless box with NFS root, running MythTV, where sudo behaves strangely.  If i run sudo once, it works as expected.  If I run it a second time shortly after, it always fails with "Permission denied".  If I wait long enough, I can run sudo again.  Once.

Version-Release number of selected component (if applicable):
kernel-3.7.6-102.fc17.x86_64 (with a workaround for bug 875216)
sudo-1.8.3p1-7.fc17.x86_64

How reproducible:
Every time.

Steps to Reproduce:
1. sudo id
2. sudo id

  
Actual results:
First time it asks for a password, and then says:
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)

Second time, it says:
bash: /usr/bin/sudo: Permission denied


Expected results:
It should work both times.

Additional info:
This machine is running with SELinux disabled, so that should not be involved.

I ran "strace -f" on the bash, to see what happened.  It turns out it is the execve(/usr/bin/sudo, ...) call succeeds the first time, but returns EACCES the second.  So the sudo program itself does not seem involved, it is the kernel that doesn't allow it to start to begin with.  My best guess is that some kind of NFS file caching is involved. but why it would prevent me from running a cached version beats me.

I attach the trace.

Root is NOT squashed here, the NFS server trusts this client.

I can run other setuid programs repeatedly without problem.  E.g., I can run "su -c id" over and over with no problem.

Comment 1 Göran Uddeborg 2013-02-18 17:33:01 UTC
Sorry, let me take that back.  The tftp server wasn't serving the kernel I thought, but an old one.  After changing that, the problem went away.


Note You need to log in before you can comment on or make changes to this bug.