Paul Eggert wrote:
[for chmod/no-x]
+ mkdir -p a/b
+ cd a
+ chmod a-x . b
+ fail=1
This indicates that "chmod a-x . b" succeeded, but it should have
failed because it should have made "." unsearchable before attempting
to access "b" (aka "./b"). Again, can you please try to see what
system calls chmod is doing, with "ktrace -o /tmp/tr chmod a-x . b"?
You are looking for this, yes?
10487 chmod CALL chmod(0x2800600,0x1a4)
10487 chmod NAMI "."
10487 chmod RET chmod 0
10487 chmod CALL chmod(0x2800600,0x1a4)
10487 chmod NAMI "b"
10487 chmod RET chmod 0
10487 chmod CALL close(0x1)
10487 chmod RET close 0
10487 chmod CALL exit(0)
Does that look right? Is chmod (the program) supposed to re-evaluate its
permissions before calling chmod() the second time (if so, that's not
happening), or is the second chmod() supposed to fail (which would mean
the OS is buggy)? If I am reading 'man 2 chmod' right, the second
chmod() is expected to fail with EACCES?
--
Matthew
Download. Untar. Configure. Make. Install. Lather. Rinse. Repeat.
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
