18

I am new to system administration and I have a permission related query. I have a group called administration. Inside the administration group, I have the users user1, user2, user3, superuser. All the users are in the administration group. Now, I need to give permissions to the user superuser to be able to view the /home directory of the other users. However, I do not want user1, user2, user3 to see the home of any other user other than himself. (That is, user1 should be able to see only user1's home and so on).

I have created the users and groups and assigned all the users to the group. How should I specify the permissions for the superuser now?

In other words, I'm thinking of having two groups (say NormalUsers and Superuser). The NormalUsers group will have the users user1, user2 and user3. The Superuser group will only have the user Superuser. Now, I need the Superuser to have full access on the files of users in the group NormalUsers. Is this possible in Linux?

2
  • How is this different from your previous question?
    – Gilles 'SO- stop being evil'
    Sep 19, 2013 at 22:13
  • In my previous question, I was more concerned with editing the /etc/sudoers file and making the user as a partial administrator. Here, I am trying to modify the permissions of a local user. Yeah, it's similar to what am trying to achieve, but am trying to approach a different method here.
    – Ramesh
    Sep 19, 2013 at 22:15

3 Answers 3

Reset to default
19

If the users are cooperative, you can use access control lists (ACL). Set an ACL on the home directory of user1 (and friends) that grants read access to superuser. Set the default ACL as well, for newly created files, and also the ACL on existing files.

setfacl -R -m user:superuser:rx ~user1
setfacl -d -R -m user:superuser:rx ~user1

user1 can change the ACL on his files if he wishes. Even if user1 is cooperating, new files may accidentally be unreadable, e.g. when untarring an archive with restrictive permissions, or because some applications deliberately create files that are only readable by the user (e.g. mail clients tend to do this).

If you want to always give superuser read access to user1's files, you can create another view of the users' home directories with different permissions, with bindfs.

mkdir -p ~superuser/spyglass/user1
chown superuser ~superuser/spyglass
chmod 700 ~superuser/spyglass
bindfs -p a+rD-w ~user1 ~superuser/spyglass/user1

Files accessed through ~superuser/spyglass/user1 are world-readable. Other than the permissions, ~superuser/spyglass/user1 is a view of user1's home directory. Since superuser is the only user who can access ~superuser/spyglass, only superuser can benefit from this. This method is automatic and user1 cannot opt out.

6
  • 1
    On my system, the permissions and the username are swapped: setfacl -R -m user:superuser:rx ~user1.
    – Mmmh mmh
    Nov 3, 2018 at 11:42
  • Nice! A small question: do you imply that i) the ACL solution will not guarantee that all new files and folder added later on will also be readable by superuser, while ii) the bindfs solution does guarantee that all files and folders added under the user1 tree in all future will always be readable? :)
    – Zorglub29
    Mar 9, 2022 at 14:44
  • one more thing: in this setup, one may have some cases in which some files, other than folders, were executable before, and the X will keep these executable also from superuser, right? Is there a way that the superuser can only read + execute dirs / read all files, and not read and execute the files that were executable from before, in a way that this is guaranteed "for all future under user1!?
    – Zorglub29
    Mar 9, 2022 at 14:51
  • 1
    @Zorglub29 With ACL, user1 can make files unreadable deliberately (chmod, setfacl) or accidentally (e.g. untarring an archive, saving an email). With bindfs, the view is created dynamically and user1 can't prevent it. With bindfs, you can use D instead of X to only apply executability to directories (I'm not sure the D flag existed when I posted this answer, but it's been around for a long time now).
    – Gilles 'SO- stop being evil'
    Mar 9, 2022 at 17:36
  • Aaahh, excellent with the D flag :) . Do you think you could update your answer with it? That may answer the initial question even better:) .
    – Zorglub29
    Mar 9, 2022 at 18:06
12

You can use ACLs to grant access to a particular directory to an arbitrary group.

For example, if you ran setfacl -m g:dba:rwx /home/foo, then members of the dba group would have rwx permissions on it, regardless of which group owns the directory.

You'll probably also want to set the "default" ACL (the ACL for newly-created objects inside the directory) to also include this permission.

7
  • yeah, exactly..I found out the same too but still not sure if it is a good idea to grant ACLs in the server for the LDAP users.
    – Ramesh
    Sep 19, 2013 at 23:01
  • @Ramesh Well, if they're users on the system (because you're using nss-ldap, sssd, etc.), then I'm not sure why it wouldn't be OK.
    – derobert
    Sep 19, 2013 at 23:03
  • I was trying to replicate this in test bed. When am logging in as the user (for example foo), I am seeing a warning message as "the permissions should be set to 644". I do believe the warning can be ignored. But, I do not want the lab users to know that their user accounts has been compromised. When I change the rwx to just r in the setfacl command, I am not able to see the foo's directory.
    – Ramesh
    Sep 19, 2013 at 23:07
  • 2
    @Ramesh You need +x to actually go through directories. I'm not sure what's telling you that a directory should be 644, that's silly, it should be 755 or similar. But either way, the user will see a + in ls's permission field, and can run getfacl to see it—its not secret.
    – derobert
    Sep 19, 2013 at 23:09
  • Alright, I was getting the warning message, User's $HOME directory must be owned by user and not writable by other users. I removed the write permission in the setacl command and now I do not see the warning message.
    – Ramesh
    Sep 19, 2013 at 23:17
-3

Unfortunately, there's not really any way to directly do this on vanilla Linux.

You might be able to create a new group in sudoers for the partial-admins with a white list of acceptable commands you want to allow them to run.

However, to achieve exactly what you are asking for, you would have to use Apparmor or SELinux to achieve what you want. Unfortunately, neither of these tools are easy to set up and use, and examples are far outside the scope of a quick answer here.

4
  • 1
    Linux has supported ACLs for a while now. ACLs let you do this.
    – derobert
    Sep 19, 2013 at 22:51
  • Yeah, I just found that solution and updated the answer. However, I still don't know if it can be used in the server and that too for LDAP users.
    – Ramesh
    Sep 19, 2013 at 23:00
  • @derobert From what I understand, it is impossible to give someone root level permissions via sudo while simultaneously using ACLs to limit access. You have to use SELinux or another MAC to achieve that.
    – Swiss
    Sep 20, 2013 at 1:29
  • 1
    I think when OP says the user "superuser", he means that literally – not root.
    – derobert
    Sep 20, 2013 at 1:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .