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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <4FFAAE6C020000A10000A6AB@gwsmtp1.uni-regensburg.de>
Date:	Mon, 09 Jul 2012 10:11:56 +0200
From:	"Ulrich Windl" <Ulrich.Windl@...uni-regensburg.de>
To:	"Ryan Mallon" <rmallon@...il.com>
Cc:	<linux-kernel@...r.kernel.org>
Subject: Re: Antw: Re: /sys and access(2): Correctly implemented?

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@...il.com> schrieb am 09.07.2012 um 09:22 in Nachricht
<4FFA86C5.7090601@...il.com>:
> On 09/07/12 16:23, Ulrich Windl wrote:
>>>>> Ryan Mallon <rmallon@...il.com> schrieb am 09.07.2012 um 01:24 in Nachricht
> > <4FFA16B6.9050009@...il.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
> 

 
 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/