Re: NFS expert, please diagnose this
> According to joost witteveen:
> > I don't really think this has anything to do with setuid stuff
> > or anything, as "ls" running as root itself doesn't see anything
> > eighter.
> ??? I don't understand. As root:
> kant# ls -la /var/spool/cron/atjobs/
And /var/spool/cron/atjobs is mounted over nfs?
Strange, I see (on the client):
rulvsa:/home/joostje/tmp# ls -al root/file
ls: root/file: Permission denied
with /home/joostje/tmp mountd via nfs. (At the moment I've got the
no_root_squash removed again, but it was the same with it enabled).
On the server:
rulcmc:/tmp# ls -al root
drwx------ 2 root root 1024 Sep 28 12:43 .
drwxrwxrwt 24 root root 8192 Sep 28 15:41 ..
-rw-r--r-- 1 root root 0 Sep 28 12:43 file
> > Yes, this looks as a bug to me.
> How do I find where it is so I can fix it? Do you think it's libc or nfsd?
Well, what _I_ see surely comes from nfsd. (netstd source).
running nfsd with
/usr/sbin/rpc.nfsd -F -d call
clearly showed that it refused to serve /tmp/root/file (result: 13,
which is access denied). But you seem to see something different
(if /var/spool/cron/atjobs is mounted over nfs, apparetnly ls
can see it).
But really, ls doens't do much else than just lstat (ok, not stat but lstat):
# strace root/file
brk(0x8058000) = 0x8058000
lstat("tmp/root/file", 0x8054d04) = -1 EACCES (Permission denied)
write(2, "ls: ", 4ls: ) = 4
write(2, "tmp/root/file", 13tmp/root/file) = 13
I don't hope changing the "stat" to "lstat" in your programme makes
any difference (if it does, you're messing up some symlinks somewhere),
but anyway, I cannot test, as the behaviour I see is at least consistent
(lstat (from ls) and stat from your stat programme both returning error):
(yes, I compiled it now).
joost witteveen, email@example.com
#what's this? see http://www.dcs.ex.ac.uk/~aba/rsa/
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
Trouble? e-mail to firstname.lastname@example.org .