AIX, user gets “pwd: The file access permissions do not allow the specified action.”

AIX, user gets “pwd: The file access permissions do not allow the specified action.”

Just a short demonstration that file permissions matter on directories used as mount points under AIX6.1. Let’s say we have properly running system, the oracle software owner user “orand3″ can access everything (pwd and ls commands):

01.root@kopsxsap003d:# mount | grep 102_64
02./dev/nd3orabin   /oracle/ND3/102_64 jfs2   Dec 03 12:00 rw,log=/dev/loglv00
03.root@kopsxsap003d:# oslevel
04.6.1.0.0
05.root@kopsxsap003d:# ls -ald /oracle/ND3/102_64
06.drwxr-xr-x   74 orand3   dba            4096 Sep 28 06:44 /oracle/ND3/102_64
07.root@kopsxsap003d:# su - orand3
08.kopsxsap003d:orand3 1> cd /oracle/ND3/102_64
09.kopsxsap003d:orand3 2> pwd
10./oracle/ND3/102_64
11.kopsxsap003d:orand3 3> ls head
12.MOPatch
13.OPatch
14.OPatch_old
15.admin
16.assistants
17.bali
18.bin
19.ccr
20.ccr_stage
21.cdata
22.kopsxsap003d:orand3 4> logout
23.root@kopsxsap003d:#

Now we simulate how the underneath mount point permission affects the users after mounting:

1.root@kopsxsap003d:# umount /oracle/ND3/102_64
2.root@kopsxsap003d:# ls -ald /oracle/ND3/102_64
3.drwxr-xr-x    2 root     system          256 Aug 23 11:16 /oracle/ND3/102_64
4.root@kopsxsap003d:#

.
As you can see it changed ownership from orand3:dba to root:system after unmounting (because in reality after unmounting /oracle/ND3/102_64 is just a directory on higer level filesystem like /oracle or /oracle/ND3):

1.root@kopsxsap003d:# mount /oracle/ND3/102_64
2.root@kopsxsap003d:# ls -ald /oracle/ND3/102_64
3.drwxr-xr-x   74 orand3   dba            4096 Sep 28 06:44 /oracle/ND3/102_64
4.root@kopsxsap003d:# umount /oracle/ND3/102_64
5.root@kopsxsap003d:# ls -ald /oracle/ND3/102_64
6.drwxr-xr-x    2 root     system          256 Aug 23 11:16 /oracle/ND3/102_64

OK, we want to show how the normal (i.e. non-root users) react to mount point directory that is not allowing access for them:

1.root@kopsxsap003d:# chmod 700 /oracle/ND3/102_64
2.root@kopsxsap003d:# ls -ald /oracle/ND3/102_64
3.drwx------    2 root     system          256 Aug 23 11:16 /oracle/ND3/102_64
4.root@kopsxsap003d:# mount /oracle/ND3/102_64
5.root@kopsxsap003d:# ls -ald /oracle/ND3/102_64
6.drwxr-xr-x   74 orand3   dba            4096 Sep 28 06:44 /oracle/ND3/102_64

See?, after the mounting it changed to 755 orand3:dba , but underneath it is still root:system with 700. So what should do the AIX kernel perform ? Let’s see…

01.root@kopsxsap003d:# su - orand3
02.kopsxsap003d:orand3 1> cd /oracle/ND3/102_64
03.kopsxsap003d:orand3 2> pwd
04.<strong>pwd: The file access permissions do not allow the specified action.</strong>
05.kopsxsap003d:orand3 3> ls head
06.MOPatch
07.OPatch
08.OPatch_old
09.admin
10.assistants
11.bali
12.bin
13.ccr
14.ccr_stage
15.cdata
16.kopsxsap003d:orand3 4> logout
17.root@kopsxsap003d:# umount /oracle/ND3/102_64
18.root@kopsxsap003d:# ls -ald /oracle/ND3/102_64
19.drwx------    2 root     system          256 Aug 23 11:16 /oracle/ND3/102_64
20.root@kopsxsap003d:#

As it was demonstrated underneath mount point permission DO HAVE an affect on non-root users for pwd command if they are not clearly visible. What’s even more interesting that typical libc routines for opening dir, reading dor – they works just fine. It is just a matter of pwd command.

Ok – let’s fix it…

1.root@kopsxsap003d:# chmod 755 /oracle/ND3/102_64
2.root@kopsxsap003d:# mount /oracle/ND3/102_64
3.root@kopsxsap003d:# su - orand3
4.kopsxsap003d:orand3 1> cd /oracle/ND3/102_64
5.kopsxsap003d:orand3 2> pwd
6./oracle/ND3/102_64
7.kopsxsap003d:orand3 3>

So what is really pwd command doing?

1.kopsxsap003d:orand3 1> type pwd
2.pwd is a shell builtin.
3.kopsxsap003d:orand3 2> echo $SHELL
4./usr/bin/csh
5.kopsxsap003d:orand3 3> /usr/bin/pwd
6./oracle/ND3
7.kopsxsap003d:orand3 4>

So you have an interal pwd command (for shell) but also real command in /usr/bin. Let’s see what’s happening there:

01.root@kopsxsap003d:# umount /oracle/ND3/102_64
02.root@kopsxsap003d:# chmod 700 /oracle/ND3/102_64
03.root@kopsxsap003d:# mount /oracle/ND3/102_64
04.root@kopsxsap003d:# su - orand3
05.kopsxsap003d:orand3 1> cd /oracle/ND3/102_64
06.kopsxsap003d:orand3 2> pwd
07.pwd: The file access permissions do not allow the specified action.
08.kopsxsap003d:orand3 3> /usr/bin/pwd
09.pwd: The file access permissions do not allow the specified action.
10.kopsxsap003d:orand3 4> truss /usr/bin/pwd
11.execve("/usr/bin/pwd", 0x2FF22984, 0x20012ED8)   argc: 1
12.sbrk(0x00000000)                                = 0x2000104C
13.vmgetinfo(0x2FF21370, 7, 16)                    = 0
14.sbrk(0x00000000)                                = 0x2000104C
15.sbrk(0x00000004)                                = 0x2000104C
16.(..)
17.statx("/", 0x2FF21178, 176, 020)                = 0
18.statx("./", 0x2FF21178, 176, 020)               = 0
19.statx("./../", 0x2FF21010, 128, 010)            Err#13 EACCES
20.access("/usr/lib/nls/msg/en_US/libc.cat", 0)    = 0
21._getpid()                                       = 8847484
22.kopen("/usr/lib/nls/msg/en_US/libc.cat", O_RDONLY) = 3
23.(..)
24.pwdkwrite(2, " p w d", 3)                               = 3
25.: kwrite(2, " :  ", 2)                          = 2
26.The file access permissions do not allow the specified action.kwrite(2, " T h e   f i l e   a c c".., 62)       = 62
27. 
28.(..)
29._exit(1)
30.kopsxsap003d:orand3 5>

So the the truth is hidden in EACCES return code for the statx() syscall.

01.kopsxsap003d:orand3 11> cd /oracle/ND3/102_64
02.kopsxsap003d:orand3 12> ls head
03.MOPatch
04.OPatch
05.OPatch_old
06.admin
07.assistants
08.bali
09.bin
10.ccr
11.ccr_stage
12.cdata
13.kopsxsap003d:orand3 13> ls -ald /oracle/ND3/102_64
14.drwxr-xr-x   74 orand3   dba            4096 Sep 28 06:44 /oracle/ND3/102_64
15.kopsxsap003d:orand3 14> ls -al /oracle/ND3/102_64/|head
16.ls: 0653-345 /oracle/ND3/102_64/..: Permission denied.
17.total 280
18.drwxr-xr-x   74 orand3   dba            4096 Sep 28 06:44 .
19.drwxr-x---   35 orand3   dba            4096 Aug 23 12:45 .patch_storage
20.drwxr-xr-x    2 orand3   dba             256 May 10 2010  MOPatch
21.drwxr-xr-x    7 orand3   dba            4096 Nov 16 2009  OPatch
22.drwxr-x---    5 orand3   dba             256 Aug 23 12:27 OPatch_old
23.drwxr-xr-x    3 orand3   dba             256 Aug 23 13:36 admin
24.drwxr-x---    7 orand3   dba             256 Aug 23 12:18 assistants
25.drwxr-x---    3 orand3   dba             256 Aug 23 12:18 bali
26.drwxr-xr-x    2 orand3   dba           16384 Aug 23 12:45 bin
27.kopsxsap003d:orand3 15> ls -al .
28.ls: 0653-341 The fil does not exist.
29.drwxr-xr-x   74 orand3   dba            4096 Sep 28 06:44 .
30.kopsxsap003d:orand3 16> ls -al .
31.ls: 0653-345 ./..: Permission denied.
32.total 280
33.drwxr-xr-x   74 orand3   dba            4096 Sep 28 06:44 .
34.drwxr-x---   35 orand3   dba            4096 Aug 23 12:45 .patch_storage
35.drwxr-xr-x    2 orand3   dba             256 May 10 2010  MOPatch
36.drwxr-xr-x    7 orand3   dba            4096 Nov 16 2009  OPatch
37.drwxr-x---    5 orand3   dba             256 Aug 23 12:27 OPatch_old
38.drwxr-xr-x    3 orand3   dba             256 Aug 23 13:36 admin
39.drwxr-x---    7 orand3   dba             256 Aug 23 12:18 assistants
40.drwxr-x---    3 orand3   dba             256 Aug 23 12:18 bali
41.[..]
42.kopsxsap003d:orand3 19> ls -ald .
43.drwxr-xr-x   74 orand3   dba            4096 Sep 28 06:44 .
44.kopsxsap003d:orand3 20> ls -ald ./..
45.ls: 0653-345 ./..: Permission denied.
46.kopsxsap003d:orand3 21> ls -ald ./../..
47.ls: 0653-345 ./../..: Permission denied.
48.kopsxsap003d:orand3 22> ls -ald /oracle/ND3/102_64
49.drwxr-xr-x   74 orand3   dba            4096 Sep 28 06:44 /oracle/ND3/102_64
50.kopsxsap003d:orand3 23>

As you saw if you are planning some non-root users (e.g. Oracle in this case) to properly work on mounted filesystems under AIX you need to have proper permissions on the mount point dir first before mounting. Ther e is no escape from this. All comes to the definition of the stat() faimiliy of system calls:

1.Description
2. 
3.The stat subroutine obtains information about the file named by the Path parameter. Read, write, or execute
4.permission for the named file is not required, but all directories listed in the path leading to the file must be
5.<strong>searchable</strong>. The file information, which is a subset of the stat structure, is written to the area specified by the
6.Buffer parameter.

“Searchable” for directory in UNIX means “+x” , so someone has to have execute bit set (+x) on the directory in order it to be searchable for system calls.

0 (0)
Article Rating (No Votes)
Rate this article
Attachments
There are no attachments for this article.
Comments
There are no comments for this article. Be the first to post a comment.
Full Name
Email Address
Security Code Security Code
Related Articles RSS Feed
Create a mksysb + SPOT using NIM (CLI)
Viewed 4201 times since Tue, Jul 17, 2018
Create jfs2 logical volume on AIX
Viewed 1726 times since Thu, Feb 21, 2019
How To Mirror Your Root Disk On AIX (a.k.a. rootvg)
Viewed 2502 times since Mon, May 21, 2018
AIX, Security, System Admin Difference between sticky bit and SUID/GUID
Viewed 6852 times since Fri, Apr 19, 2019
AIX: Configuring a network interface
Viewed 1592 times since Sat, Jun 2, 2018
Monitoring Events with AIX Audit
Viewed 2355 times since Wed, May 30, 2018
View mksysb content & restore individual files
Viewed 913 times since Tue, Jul 17, 2018
Understanding dump devices sysdumpdev
Viewed 1755 times since Mon, Jul 9, 2018
Creating Normal,Big,Scalable VG on AIX
Viewed 9430 times since Fri, Feb 1, 2019
AIX Resolving "missing" or "removed" disks in AIX LVM
Viewed 1958 times since Tue, Aug 6, 2019