I need to discover which are the permissions of a user in a CentOS system. Is it possible to find which are the directories the user can access and the command he can execute? It doesn't refer to ACL's.
-
You would have to look at using the find command – Raman Sailopal Jan 19 '18 at 14:19
-
2Possible duplicate of Do we have log for ACL ..? – Chris Davies Jan 19 '18 at 14:30
-
@roaima Not really since the question does not mention ACLs. – Kusalananda Jan 19 '18 at 14:55
-
i think Kusalananda's answer is perfect. I can adapt it in according to specific needs. thanks – intore Jan 19 '18 at 15:32
-
What, exactly, are you saying by your edit? Are you saying that you’ll accept an answer that gives wrong results if the system has ACLs? – G-Man Says 'Reinstate Monica' Jan 20 '18 at 02:08
1 Answers
To be able to execute a file, the file must
- Be owned by the user and be executable by the user, or
- Belong to the same group as the user and be executable by that group, or
- Be executable by "others".
The following find
command find such files in the current directory (for the current user and their primary group only):
uid=$( id -u ) # the user's ID
gid=$( id -g ) # the primary group ID
find . -type f \( \
\( -user "$uid" -perm -0100 \) -o \
\( -group "$gid" -perm -0010 \) -o \
-perm -0001 \) -print
-0100
means "at least executable by user", and -0010
and -0001
are the equivalent for "group" and "others".
The same criteria holds or accessibility of folders (if I'm not entirely mistaken), so changing -type f
to -type d
should give you the accessible folders. One may additionally want to check the folders for the "read" bit too, obviously (-0500
, -0050
and -0005
instead of the permissions above).
For folders, this may be a solution:
find . -type d \( \
\( -user "$uid" -perm -0500 \) -o \
\( -group "$gid" -perm -0050 \) -o \
-perm -0005 -o -prune \) -print
I've added -prune
at the end so that we don't descend into folders that the user wouldn't be able to access anyway.
Change the dot to a slash to search on the whole system.
It's also easy to turn it around to only print the names of e.g. folders that the user can't access:
find . -type d \( \
\( -user "$uid" -perm -0500 \) -o \
\( -group "$gid" -perm -0050 \) -o \
-perm -0005 -o -print -prune \)

- 333,661
-
The question is somewhat vaguely / unclearly worded. (1) “command(s) [the user] can execute” arguably includes all executables that he owns, because he can always
chmod
them to give himself execute access — so the-perm -0100
test might not be a real restriction. (2) It also arguably includes all executables he can read, because he can make a copy of them (although he wouldn’t be able to preserve setuid / setgid bits). (3) And it doesn’t include (interpreted) scripts to which he has only execute access, but not read access. … (Cont’d) – G-Man Says 'Reinstate Monica' Jan 20 '18 at 02:01 -
(Cont’d) … Your statement of the permission-checking algorithm is slightly flawed. For every attempted access, the system looks at only one group of three bits. It looks at the 0070 bits only if the user doesn’t own the file, and it looks at the 0007 bits only if the 0700 and 0070 bits don’t apply. (4) So your command give this (fairly trivial) false positive: if
fred
owns an executable file andchmod
s it 645, 654 or 655, then he won’t have execute access, but yourfind
command will say that he does. (5) A slightly more significant false positive: … (Cont’d) – G-Man Says 'Reinstate Monica' Jan 20 '18 at 02:01 -
(Cont’d) … if a file is owned by
george
but is infred
’s group, and is protected 745, then, again,fred
won’t have execute access, but yourfind
command will say that he does. (6) A more significant omission: your code doesn’t handle the fact that a user can be in multiple groups. If a file is owned bygeorge
but is in one offred
’s secondary groups, and is protected 745, then, again,fred
won’t have execute access, but your command will say that he does. Conversely, if it is protected 754, then he will have access, but your command will say that he doesn’t (false negative). – G-Man Says 'Reinstate Monica' Jan 20 '18 at 02:01 -
@G-Man 1) A file without executable permissions is not an executable at that point in time. Yes, one could
chmod
it to be executable, but then again, one could do that with any file. 2) An executable that he can read but not execute is not an executable, so that's ok. 3) True, it should not include non-readable scripts. Changing it to the same permissions as for the folders case would solve that. – Kusalananda Jan 20 '18 at 07:05 -
@G-Man 4) and 5) Yes, there are cases like that too. I'll see if I can fix that during some time soon. 6) I only check the primary group. Doing the secondary groups is a matter of introducing a trivial loop. – Kusalananda Jan 20 '18 at 07:08
-
@G-Man. thanks for you contribute. The Kusalananda's script helps me and I can change it in according to my needs. Also with your corrections/clarifications. Anyway I accept the Kusalananda's answer. – intore Jan 20 '18 at 12:42