9

I want to give an access to a dir for a friend. He has the access to the file system, where the dir is located. I don't want to set the permissions to all users. How can I allow only a person to see the dir? None of us is a superuser.

[BOUNTY CHALLENGE] None of the replies work, using Ubuntu:

1. jamuraa's Approach not working

$ setfacl -m user:friend:rwx classroom.xml 
setfacl: classroom.xml: Operation not supported

2. nik's Approach not working: cannot access non-existent file

3. ba's Approach not working: I cannot create groups, not a root.

4. ToK's Approach not working, users are in two groups: "users" and "field"

chown -R myFriend:users ~/TEST
chown: changing ownership of `/u/myFriend/TEST/you_see_it': Operation not permitted
chown: changing ownership of `/u/myFriend/TEST': Operation not permitted
2
  • 1
    It would be useful if you gave a one-liner on how these answers pose a problem for you -- would give a better problem definition for forming other options.
    – nik
    Nov 19, 2010 at 1:57
  • nik: Added error profiles.
    – user3672
    Nov 24, 2010 at 2:32

11 Answers 11

12

With just normal UNIX permissions (user, group, everyone), you can't do this easily. If you don't need access to the directory anymore, you can possibly change the owner of the directory to your friend, which is valid on some Unices, but most of them it is not.

However - if you have ACLs enabled on Linux, you can do this if you are the owner of the file. Just run the command setfacl -m user:friend:rwx filename where friend is the account name of your friend and filename is the file. You can check that it went into effect by running getfacl filename, you should see the triad user:friend:rwx in the list. I haven't seen too many Linux systems which have the ACLs enabled though.

3
  • ACLs are the standard solution to this problem, assuming that your filesystem has them enabled. Nov 18, 2010 at 4:17
  • HHH seems to say that this won't work. I think it would, unless for some odd reason ACLs aren't enabled. HHH, what gives?
    – pboin
    Nov 18, 2010 at 12:55
  • pboin: this method does not work so apparently the reason may be that ACLs are not enabled or s/thing else, not sure.
    – user3672
    Nov 24, 2010 at 2:06
11

This is something we had discussed back in school.
Goes roughly like this,

  1. Create a directory (named data, for reference here)
    • change permissions as "chmod 711 data"
    • group and others have only x -- access to enter the directory
    • they cannot list the directory
    • Now, create a directory difficult-name-here (this could be a hashed-string)
    • change permissions as "chmod a+rx difficult-name-here"
    • contents of this directory are secure while the outer directory cannot be listed
    • people who know the "difficult name" can jump into this second directory
      • "cd path/to/data/difficult-name-here"
      • others cannot see the name and cannot access directory contents
      • However, the root can always access everything (which is not a problem here)
    • share the difficult-name-here with the people you want to give this data
    • Keep shared files in this second directory

Quite crude, but if this can be broken without the unix access control breakage, I'd like to know.


Update on comment from dmckee,
This is exactly the conclusion we reached!
"security by obscurity" has limited safety.

Having said that, when designing protection for data,
it is important to identify its value.

You should target for,

  • A Cost of breaking-the-security that is higher than,
  • The Cost of secured content,
  • By a factor proportional to your paranoia

In this case, if the root decides to enumerate the directory tree somewhere in public access,
your secret is out! But, are you protecting from the root or their potential irresponsibility?
If that is the case, you have a lot more to worry about then shared files.


Update about not-working note in the question.
I've used this in early days of linux to know that it works.
If you get 'cannot access non-existant file' instead of 'permissions denied' you have very likely made a mistake in the sequence. What you want should look like this,

 755      711      755     whatever     --=== Access permissions

 BasePath/CoverDir/Obscure/protectedFile.txt
          |        |       ^^^^^^^^^^^^^^^^^ Can't be seen without 
          |        ^^^^^^^ Directory Name         read access to 
          ^^^^^ Public     shared with friend.    Obscure directory.
                accessible 
                directory.
  1. If you set 'CoverDir' access as 'rwx--x--x',
    group and others can only enter the directory but cannot read its contents.
  2. Now, if you use an obscure directory name,
    'Obscure', inside it and give full read access with 'rwxr-xr-x',
    anyone knowning this name can list its contents.
  3. This access will have to be done from outside with a 'ls BasePath/CoverDir/Obscure'
    Because people in your group and others will not be able to 'ls BasePath/CoverDir'.
2
  • 7
    "if this can be broken [...], like to know" Well, it is the very exemplar of security by obscurity, and thus fragile. Don't count on in it long term. Neat, though. Sep 3, 2009 at 13:49
  • If your unix access control is safely implemented, this is almost as safe as a shadowed password database (or ssh private key).
    – nik
    Sep 4, 2009 at 19:51
5
+100

Ryan was actually 100% correct, just backward. Since your friend (likely) has a unique group associated with his/her user name change the group ownership of the directory in question to that group, most likely the friend's user name. In order to be able to share the contents between the two of you you should retain ownership as the user:

chown -R youruser:friendgroup ~/foo/bar

Then assign appropriate permissions to the directory, dependent upon what access you wish the other user to have:

chmod -R 770 ~/foo/bar

would grant both of you full rwx access to the directory and its entire contents.

Please note that this assumes that no other user has been added to your friend's group. The system would not have likely have made this assignment, however, as was mentioned before, the root user may do what they choose. You may use the groups command to see each group to which your friend, or arbitrary user, belong. Additionally, unless the permissions have been changed for some reason, you should be able to view the /etc/group file which contains the group assignments for each group on the system.

4

I would make a new group for you and your friend and set the folder permissions to full for owner and group together with the setgid bit for the directory.

But depending on your needs you may also have to look into changing you and your friends umask so it automatically sets the group to be able change new files.

# groupadd bestfriends
# chmod 2770 dir
# chgrp bestfriends dir
# usermod -G bestfriends FRIENDLOGIN
2
  • 3
    This may require superuser privledges that he doesn't have.
    – Keck
    Sep 3, 2009 at 13:57
  • 1
    Oh, I completely missed that line :x Then I'm at a loss. Guess I'd just go with sending it over mail locally -- not the best solution but at least the file gets across to the other guy.
    – gaqzi
    Sep 3, 2009 at 14:07
2

Access Control Lists are the perfect way to do this.

However (if I remember correctly), the file system needs to be initialized with ACLs (e.g. "/dev/sda6 /home ext3 defaults,acl"), via /etc/fstab, and this is something that only the superuser can do...

2

RBACS like grsec/selinux is required..

1
  • not sure whether this is the problem, can you add some citation?
    – user3672
    Nov 24, 2010 at 2:04
2

By default, each user on an Ubuntu system also has an associated group of the same name. So if you can add your friend to your group and then mark the folder in question as g+rwx, you'll be set. I vaguely remember this use case being cited as the reason to create a group for each user.

1
  • Adding users to groups requires root access, which OP said he doesn't have. Nov 18, 2010 at 9:57
2

haven't tried this, but how about a public readable directory with an encrypted user-space FS inside (for example encfs). Then you can share that password with your friend and no one else can make use of that data (well, I guess they could get the data and run a password cracker offline?).

2

To give Linux the same Finesse as windows in file privileges you have to nest groups. Create one group that has access to your folder as you would like your friend to have. Add him to that group or the group he resides in to that group. For example

/foo is the folder you want to share. Create a group FooGroup that has the desired access to the folder. Add groups and users to this group which you want to have said access to this folder.

It is a big pain to have a group for each folder or file but it is the best way to restrict access at the same level as Windows.

1

How about Dropbox? You can install it without admin privileges and both link to the same account.

Check out How To Install Dropbox In An Entirely Text Based Linux Environment

1
  • 1
    sorry but looking something more 'basic', more interested in mhambra's approach
    – user3672
    Nov 24, 2010 at 2:08
1

You could encrypt the directory with gpg. And then try to obfuscate the location like how nik suggested.

You must log in to answer this question.