4

How do I get a list of all the files which permission is "read and write" for a specific user.

For example, when I go on the desktop of my mac, then right click on file "A", then "get info", then on the bottom I have "share and permission" where I can add a custom user like "popo" for example, and then specify that he can "read and write" that file.

Then I want to use a command line to get all the files that POPO can read and write, and only these (I want to get "A" in the above example).

All my researches lead me to for now is something like :

find /Users/Me/Desktop -user popo -perm 777

But I get nothing..

What's wrong with the above findand how should I proceed?

user
  • 28,901
lapin
  • 299

3 Answers3

3

You need to search for files that are RW by everyone OR are RW by the user's uid OR that are RW by all groups that the user is a member of. But it's a bit more complicated than that. As pointed out by here by Stephane Chazelas, if a file is owned by a user then ONLY the owner perms count, and if a file is owned by a group that the user is a member of then only the group perms count.

So we need to check for "owner=RW or (not owner and group=rw) or (not owner and not group and other=rw)"

You can get a list of the group gids that a user is a member of with id -G. This can be used to construct a find command line with standard shell command substitution.

My original answer had a one-liner, but this jobs is far too complex to want to do in a one-liner. Here's a bash shell script that does the job.

#! /bin/bash

U="$1"      # username to do perm search on - e.g. popo
TOPDIR="$2" # starting directory for search - e.g. /Users/Me/Desktop

# permissions to search for - defaults to "rw"
PERMS=${3:-rw}

# permission bits "style".  "/"=ANY or "-"=ALL. defaults to / 
#
# see find(1) and search for '-perm -mode' or '-perm /mode' for 
# details on how this works.
PSTYLE=${4:-/}

# construct a find expression specifying all groups that the user
# is a member of
GIDS="$(for i in $(id -G "$U"); do echo -n " -gid $i -o "; done)"
GIDS=$(echo "$GIDS" | sed -e 's/ -o $//')    # strip trailing " -o "

find "$TOPDIR" \
   \( -user "$U" -perm ${PSTYLE}u=$PERMS \) \
   -o \( -not -user "$U" -a \( $GIDS \) -perm ${PSTYLE}g=$PERMS \) \
   -o \( -not -user "$U" -not \( $GIDS \) -perm ${PSTYLE}o=$PERMS \) 

This script has to be run as root. Other users may not have the required permissions to look in all directories that popo can.

Note: I have tested this on a Debian Linux system using the latest versions of id from GNU Coreutils and find from GNU findutils. The Mac implementations of id and find may be different, I don't have a Mac available at the moment to test. If it is different, check the Mac man pages for id and find - the things to look for that might require modifying to suit a Mac are the -G and -u options for id and the -perm / or '-perm -' options of find.

cas
  • 78,579
  • actually, those find commands will ignore world-readable files that aren't owned by popo or readable by popo's groups. need to add /-perm o+r -o immediately before ... -uid. i've updated the answer. – cas Sep 19 '13 at 08:13
  • I misread the question at first, I thought you only wanted to find all readable files, not RW files. have updated the answer to find RW files. – cas Sep 19 '13 at 08:24
  • 1
    That doesn't work either. If the file is world readable, popo still doesn't have access to it if the group doesn't have read access and popo is a member of that group or if he owns the file and there's not read permission for the user. See also http://unix.stackexchange.com/a/88591/22565 – Stéphane Chazelas Sep 19 '13 at 09:06
  • that's why the find has separate logically-ORed match expressions for world-RW OR user-RW OR group-RW. even so, it's best to run the find as root, as the owner the search directory (/Users/Me/Desktop in this case) iff that owner has read perm on all subdirs. – cas Sep 19 '13 at 12:07
  • What I meant is that your script says popo has read access on a file with -------rwx popo popo while he hasn't. – Stéphane Chazelas Sep 19 '13 at 13:02
  • if it's world-readable, he should (and IIRC does) have read access - even if it's not owner- or group- readable. – cas Sep 19 '13 at 15:13
  • 1
    That's what you have wrong. When the process owner matches the file owner, only the user permissions are considered. Otherwise, if the file group matches any of the groups of the process then the group permissions are considered. The "others" permissions are only considered if the user and group don't match. Do a chmod 7 on one of your files, and you lose access to it. See http://unix.stackexchange.com/a/88591/22565 – Stéphane Chazelas Sep 19 '13 at 15:18
  • ok, i should stop thinking of it as world-readable and remember that it's actually OTHER-readable. (or writable/exec as the case may be) – cas Sep 19 '13 at 16:27
  • so, then, the script and the find command only runs correctly as root if any files are mode 007. a rare event so good enough for most cases, but something to be aware of. – cas Sep 19 '13 at 16:30
  • 1
    007 was just an example. And there's all the other issues mentioned at http://unix.stackexchange.com/a/88591/22565 where you'll also find a correct way to write that find command. – Stéphane Chazelas Sep 19 '13 at 16:43
2

That is because -user option searches files where specified user if file owner and that is not your case.

It looks like the easiest way to do what you want is to execute the command under popo user:

find /Users/Me/Desktop -readable
rush
  • 27,403
  • That fails to find files in directories that popo has search access to but not read access to. That's why in the solution I gave, I build the file list as root as checks for access as the corresponding user. – Stéphane Chazelas Sep 19 '13 at 10:31
  • This would work on Linux (barring the corner case that Stephane mentions) but OSX's find has no -readable option. – Gilles 'SO- stop being evil' Sep 19 '13 at 21:36
1
sudo find . -print0 | 
  sudo -u popo perl -Mfiletest=access -l -0ne '
    print if -r && -w'

See that answer to an almost identical question for why checking the permissions generally doesn't work.