Sam D. wrote in post #1081722:
On 10/29/2012 09:18 AM, Jeff M. wrote:
Well, that’s how Unix works. I have two objections:
(1) You should not be using superuser account for regular work!
(2) You have no business running irb in /proc filesystem!
If you do either of these things, you better not be surprised, ever!
And if you ‘regular work’ involves interrogating the /proc file system,
You could use something like this? You’d need to flesh out some error/
input handling, and these constants (sadly not exposed by ruby that I
can find) will be platform specific. I think the ‘problem’ is that root
can do pretty much anything it wants (make a file owned root:root, chmod
000, and enjoy echo’ing stuff into it). The stdlib seems to use
‘eaccess( path, R_OK )’ which I guess gives a 0 for euid 0.
S_IFMT = 0170000
S_IRUSR = 00400
S_IRGRP = 00040
S_IROTH = 00004
def readable?( path, follow=false )
st = File.lstat( path )
if follow && ( S_IFLNK == ( st.mode & S_IFMT ) )
st = File.stat( path )
uid = Process.euid
if ( st.mode & S_IROTH ) > 0
print ‘Other read’
elsif( ( ( st.mode & S_IRUSR ) > 0 ) && ( st.uid == uid ) )
print ‘Owner read’
elsif ( st.mode & S_IRGRP ) > 0
username = Etc.getpwuid( uid ).name
if Etc.getgrgid( st.gid ).mem.include?( username )
print ‘Group read’
Sam, Thanks for this.
It wasn’t exactly what I expected but it focused on all the right issues
and that has lead to a conclusion.
As you pointed out, eaccess is the key.
If the stdlib implements eaccess with the same behavior as the
implementation in file.c (line 1034), root is simply granted
read and write permission without ever hitting stat.
‘ls -al’, on the other hand, relies on stat.