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
  • 2
    Possible duplicate of Do we have log for ACL ..? – roaima 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 Jan 20 '18 at 2:08

To be able to execute a file, the file must

  1. Be owned by the user and be executable by the user, or
  2. Belong to the same group as the user and be executable by that group, or
  3. 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 \)
  • 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 Jan 20 '18 at 2: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 and chmods it 645, 654 or 655, then he won’t have execute access, but your find command will say that he does.  (5) A slightly more significant false positive:  … (Cont’d) – G-Man Jan 20 '18 at 2:01
  • (Cont’d) …  if a file is owned by george but is in fred’s group, and is protected 745, then, again, fred won’t have execute access, but your find 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 by george but is in one of fred’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 Jan 20 '18 at 2: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 7: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 7:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.