Project Home
Project Home
Documents
Documents
Wiki
Wiki
Discussion Forums
Discussions
Project Information
Project Info
BroadcastCommunity.qnx.com will be offline from May 31 6:00pm until June 2 12:00AM for upcoming system upgrades. For more information please go to https://community.qnx.com/sf/discussion/do/listPosts/projects.bazaar/discussion.bazaar.topc28418
Forum Topic - access() not behaving as expected: (3 Items)
   
access() not behaving as expected  
The POSIX call access() seems to behave not as expected on QNX. According to the doc, access() uses the *real* user ID 
to check if a file can be accessed. The Linux call effectively does this. But on QNX, it seems to use the *effective* 
user ID.

Test environment: QNX 7.1.0

Setup (a file only readable by root, 2 versions of the tool readable, one suid, one not) (the tool readable is the 
example from the access() documentation with some printf() statements for the different IDs):
$ ls -al
total 55
drwxr-xr-x   2 root      root           4096 Jun 12 01:36 .
drwxr-xr-x   6 root      root           4096 Jun 12 01:36 ..
-rw-------   1 root      root             74 Jun 12 01:36 data
-rwxr-xr-x   1 root      root           9696 Jun 12 01:31 readable
-rwsr-xr-x   1 root      root           9696 Jun 12 01:35 readable_suid

Test output:
$ ./readable data
geteuid(): 1000 - effective user ID
getegid(): 4004 - effective group ID
getuid():  1000 - user ID
getgid():  4004 - group ID
data: Permission denied
=> as expected

$ ./readable_suid data
geteuid(): 0 - effective user ID
getegid(): 4004 - effective group ID
getuid():  1000 - user ID
getgid():  4004 - group ID
ok to read data

=> The last response ("ok to read data") is unexpected because the code is running with real user ID 1000. When doing a 
similar test on Linux, I get "permission denied".

Is my understanding of access() wrong, or is this a bug in QNX or my configuration?
Attachment: Text readable.c 660 bytes
Re: access() not behaving as expected  
You will find that if you check W_OK instead if R_OK it will behave as you expect (and the same as Linux).

The reason that R_OK behaves differently is due to procmgr abilities. There is an ability iofunc/read that allows read 
access to files denied by POSIX permissions. Testing of this ability is always based on effective user ID. By default 
root has this ability so when you call access(R_OK) with the setuid root executable, it fails the POSIX access checks 
but gets overridden by the ability.

If you deny the ability in the shell:

    ability deny,all,inherit,able=iofunc/read

you will now find it behaves as you expect.

This could be considered a bug, probably everything in the call to access() should be based on real ID. The workaround 
is to deny the ability. There are few legitimate uses for the ability irrespective of this issue we'd recommend denying 
the ability since it tends to mask file system permission issues. I will however log it as a bug.
Re: access() not behaving as expected  
Thanks for the detailed explanation!

Indeed, after denying the ability everything works as expected.

We also tried another solution: temporarily dropping privileges to open the file. That works always as expected. And in 
fact that's the more secure solution anyway (no race condition between permission check/using file), so we should have 
done that first.