Hi,

I just found out that '/bin/test -x /etc/passwd' gives the right value 
(1, not executable) in $? when executed with uid!=0, but 0 (executable) when 
ran as root (assuming /etc/passwd is *not* executable).

This seems to be a misfeature, that's also documented in access(2):
     Even if a process has appropriate privileges and indicates success for
     X_OK, the file may not actually have execute permission bits set.  Like-
     wise for R_OK and W_OK.

While reading & writing everything is ok for root, i see a problem here 
for executing things. It's mildly annoying if you check if a script's 
executable or not, and you can't rely on what /bin/test gives you 
(/bin/test uses access(2)). Not to speak that this might be a security 
problem, too.

So much for the griping.

I've startet digging in the kernel source, and my first attempt was to 
just change vaccess() to return an EACCES if (acc_mode & VEXEC && 
file_mode & S_IXUSR), but that's not the deal: booting a kernel doing so 
didn't even get halfways into singleuser due to several calls getting 
EACCESS (sorry i can't tell much more, debugging via printf() isn't that 
fun, didn't get a 1.2/i386 kernel with options DDB to compile :-/).

The problem seems to be that vaccess() gets not only called via 
sys_access() but also internally via VOP_ACCESS in many places, and that 
many of them (seem to) rely on the fact that they get execute-access even 
if a file (directory? whatever!) isn't executable. 

What's the right solution to this - handle the vnode(type) to vaccess and 
return EACCES? (I'm not really familiar with this stuff X-)

Also, what should the semantics be for allowing root to execute a file? 
If the owner can execute it? If any of user/group/other can execute it?


Hubert

P.S.: Is there some keystroke to jump into DDB (if i ever get it built)
      on my 1.2/i386? Or how does one do kernel debugging? (Don't tell
      me with printf() and panic(), please .-)

--
Hubert Feyrer <hubert.feyrer@rz.uni-regensburg.de>