eaccess question

[David Lutterkort]

Hi,

I am trying to track down a change in behavior in Fedora's ruby
interpreter from version 1.8.4 to 1.8.5. The issue is caused by
ruby-1.8.5 using eaccess for file access checks where it used to use its
own code before. The intent of the checks is to see if the effective
user can read/write/exec etc. a file.

The attached little test program simulates what happens, and what leads
to problems using eaccess. What this program would expect is that after
changing euid/egid, eaccess denies write access to a mode 0700 directory
owned by root - but surprisingly, eaccess returns 0 on a number of RH
distros I tried, e.g. glibc-2.5-3 on FC6

Is my understanding of eaccess ('do the same check as access but against
euid/egid') wrong ? What is the exact intent of eaccess ? Jim Meyering
pointed out that the eaccess implementation falls back to access if the
process is run as root when _LIBC is defined (in
libc/sysdeps/posix/euidaccess.c) which clearly does not mesh with my use
of it.

David



-------------- next part --------------
A non-text attachment was scrubbed...
Name: eaccess.c
Type: text/x-csrc
Size: 1121 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20070108/0b9f395e/attachment.bin>