/sys and access(2): Correctly implemented?

/sys and access(2): Correctly implemented?

[Ulrich Windl]

Hi!

Recently I found a problem with the command (kernel 3.0.34-0.7-default from SLES 11 SP2, run as root):
test -r "$file" && cat "$file"
emitting "Permission denied"

Investigating, I found that "test" actually uses "access()" to check for permissions. Unfortunately there are some files in /sys that have "write-only" permission bits set (e.g. /sys/devices/system/cpu/probe).

~ # ll /sys/devices/system/cpu/probe
--w------- 1 root root 4096 Jun 29 12:43 /sys/devices/system/cpu/probe
~ # F=/sys/devices/system/cpu/probe
~ # test "$F" && cat "$F"
cat: /sys/devices/system/cpu/probe: Permission denied

In times of capabilities and ACLs, shouldn't there be a test for permissions that actually works?

Regards,
Ulrich
P.S. Please make sure my CC: gets your replies, too -- thanks

Re: /sys and access(2): Correctly implemented?

[Ryan Mallon]

On 06/07/12 16:27, Ulrich Windl wrote:
> Hi!
> 
> Recently I found a problem with the command (kernel 3.0.34-0.7-default from SLES 11 SP2, run as root):
> test -r "$file" && cat "$file"
> emitting "Permission denied"
> 
> Investigating, I found that "test" actually uses "access()" to check for permissions. Unfortunately there are some files in /sys that have "write-only" permission bits set (e.g. /sys/devices/system/cpu/probe).
> 
> ~ # ll /sys/devices/system/cpu/probe
> --w------- 1 root root 4096 Jun 29 12:43 /sys/devices/system/cpu/probe
> ~ # F=/sys/devices/system/cpu/probe
> ~ # test "$F" && cat "$F"
> cat: /sys/devices/system/cpu/probe: Permission denied

Looks like you have a typo here, I think you wanted "test -r $F", not
"test $F", the latter will just evaluate "$F" as an expression which
will be true, and so you get the permission denied error running cat.

Using "test -r $F" on a write-only sysfs file correctly returns false on
my machine (Ubuntu 10.04.4 LTS/2.6.32-41-generic).

~Ryan

Antw: Re: /sys and access(2): Correctly implemented?

[Ulrich Windl]

>>> Ryan Mallon <rmallon@gmail.com> schrieb am 09.07.2012 um 01:24 in Nachricht
<4FFA16B6.9050009@gmail.com>:
> On 06/07/12 16:27, Ulrich Windl wrote:
> > Hi!
> > 
> > Recently I found a problem with the command (kernel 3.0.34-0.7-default from 
> SLES 11 SP2, run as root):
> > test -r "$file" && cat "$file"
> > emitting "Permission denied"
> > 
> > Investigating, I found that "test" actually uses "access()" to check for 
> permissions. Unfortunately there are some files in /sys that have "write-only" 
> permission bits set (e.g. /sys/devices/system/cpu/probe).
> > 
> > ~ # ll /sys/devices/system/cpu/probe
> > --w------- 1 root root 4096 Jun 29 12:43 /sys/devices/system/cpu/probe
> > ~ # F=/sys/devices/system/cpu/probe
> > ~ # test "$F" && cat "$F"
> > cat: /sys/devices/system/cpu/probe: Permission denied
> 
> Looks like you have a typo here, I think you wanted "test -r $F", not
> "test $F", the latter will just evaluate "$F" as an expression which
> will be true, and so you get the permission denied error running cat.

Hi!

You are right: It's a typo, but only in the message; the actual test was done correctly, and the outcome is quite the same.

> 
> Using "test -r $F" on a write-only sysfs file correctly returns false on
> my machine (Ubuntu 10.04.4 LTS/2.6.32-41-generic).

Not here, unfortunately:
# ll /sys/devices/system/cpu/probe
--w------- 1 root root 4096 Jul  2 11:52 /sys/devices/system/cpu/probe
# F=/sys/devices/system/cpu/probe
# test -r "$F" && cat "$F"
cat: /sys/devices/system/cpu/probe: Permission denied
# uname -a
Linux h07 2.6.32.59-0.3-default #1 SMP 2012-04-27 11:14:44 +0200 x86_64 x86_64 x86_64 GNU/Linux

Regards,
Ulrich

Re: Antw: Re: /sys and access(2): Correctly implemented?

[Ryan Mallon]

On 09/07/12 16:23, Ulrich Windl wrote:
>>>> Ryan Mallon <rmallon@gmail.com> schrieb am 09.07.2012 um 01:24 in Nachricht
> <4FFA16B6.9050009@gmail.com>:
>> On 06/07/12 16:27, Ulrich Windl wrote:
>>> Hi!
>>>
>>> Recently I found a problem with the command (kernel 3.0.34-0.7-default from 
>> SLES 11 SP2, run as root):
>>> test -r "$file" && cat "$file"
>>> emitting "Permission denied"
>>>
>>> Investigating, I found that "test" actually uses "access()" to check for 
>> permissions. Unfortunately there are some files in /sys that have "write-only" 
>> permission bits set (e.g. /sys/devices/system/cpu/probe).
>>>
>>> ~ # ll /sys/devices/system/cpu/probe
>>> --w------- 1 root root 4096 Jun 29 12:43 /sys/devices/system/cpu/probe
>>> ~ # F=/sys/devices/system/cpu/probe
>>> ~ # test "$F" && cat "$F"
>>> cat: /sys/devices/system/cpu/probe: Permission denied
>>
>> Looks like you have a typo here, I think you wanted "test -r $F", not
>> "test $F", the latter will just evaluate "$F" as an expression which
>> will be true, and so you get the permission denied error running cat.
> 
> Hi!
> 
> You are right: It's a typo, but only in the message; the actual test was done correctly, and the outcome is quite the same.
> 
>>
>> Using "test -r $F" on a write-only sysfs file correctly returns false on
>> my machine (Ubuntu 10.04.4 LTS/2.6.32-41-generic).
> 
> Not here, unfortunately:

Oops, I missed the bit about you running as root. I get the same results
running as root on my machine as you, both for sysfs and regular files.

It appears that access(2) as the super-user is might be implementation
defined, see:

  http://pubs.opengroup.org/onlinepubs/000095399/functions/access.html
  http://lists.gnu.org/archive/html/bug-bash/2010-07/msg00071.html

However, I can't find any concrete information on it for Linux, and the
manpage doesn't mention anything other the the X_OK bit.

~Ryan

Re: Antw: Re: /sys and access(2): Correctly implemented?

[Ulrich Windl]

Hi!

Still the problem seems to be related to the sysfs:
# cd /tmp
# touch testfile
# chmod u=w,go= testfile
# F=/tmp/testfile
# test -r "$F" && cat "$F"

So it seems access(2) works correctly for root and "normal" filesystems. That's why I came up with the issue here.

Regards,
Ulrich

>>> Ryan Mallon <rmallon@gmail.com> schrieb am 09.07.2012 um 09:22 in Nachricht
<4FFA86C5.7090601@gmail.com>:
> On 09/07/12 16:23, Ulrich Windl wrote:
>>>>> Ryan Mallon <rmallon@gmail.com> schrieb am 09.07.2012 um 01:24 in Nachricht
> > <4FFA16B6.9050009@gmail.com>:
> >> On 06/07/12 16:27, Ulrich Windl wrote:
> >>> Hi!
> >>>
> >>> Recently I found a problem with the command (kernel 3.0.34-0.7-default from 
> >> SLES 11 SP2, run as root):
> >>> test -r "$file" && cat "$file"
> >>> emitting "Permission denied"
> >>>
> >>> Investigating, I found that "test" actually uses "access()" to check for 
> >> permissions. Unfortunately there are some files in /sys that have 
> "write-only" 
> >> permission bits set (e.g. /sys/devices/system/cpu/probe).
> >>>
> >>> ~ # ll /sys/devices/system/cpu/probe
> >>> --w------- 1 root root 4096 Jun 29 12:43 /sys/devices/system/cpu/probe
> >>> ~ # F=/sys/devices/system/cpu/probe
> >>> ~ # test "$F" && cat "$F"
> >>> cat: /sys/devices/system/cpu/probe: Permission denied
> >>
> >> Looks like you have a typo here, I think you wanted "test -r $F", not
> >> "test $F", the latter will just evaluate "$F" as an expression which
> >> will be true, and so you get the permission denied error running cat.
> > 
> > Hi!
> > 
> > You are right: It's a typo, but only in the message; the actual test was 
> done correctly, and the outcome is quite the same.
> > 
> >>
> >> Using "test -r $F" on a write-only sysfs file correctly returns false on
> >> my machine (Ubuntu 10.04.4 LTS/2.6.32-41-generic).
> > 
> > Not here, unfortunately:
> 
> Oops, I missed the bit about you running as root. I get the same results
> running as root on my machine as you, both for sysfs and regular files.
> 
> It appears that access(2) as the super-user is might be implementation
> defined, see:
> 
>   http://pubs.opengroup.org/onlinepubs/000095399/functions/access.html 
>   http://lists.gnu.org/archive/html/bug-bash/2010-07/msg00071.html 
> 
> However, I can't find any concrete information on it for Linux, and the
> manpage doesn't mention anything other the the X_OK bit.
> 
> ~Ryan
>