20

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?

Improve this question
2
  • How is this different from your previous question? Commented 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. Commented 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.

Improve this answer
6
  • 1
    On my system, the permissions and the username are swapped: setfacl -R -m user:superuser:rx ~user1. Commented 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? :) Commented 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!? Commented 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). Commented Mar 9, 2022 at 17:36
  • 1
    @Gilles'SO-stopbeingevil' I was reading the doc of bindfs in more details, wonder now if the -r option may be an even simpler way to get a read-only view: "-r, -o ro Make the mount strictly read-only. This even prevents root from writing to it. ". I am currently using a command in the kind of sudo /usr/bin/bindfs -r -u $(id -u) -g $(id -g) src dest, works like a charm :) . Commented Mar 13, 2022 at 15:09
13

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.

Improve this answer
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. Commented 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. Commented 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. Commented 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. Commented 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. Commented 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.

Improve this answer
4
  • 1
    Linux has supported ACLs for a while now. ACLs let you do this. Commented 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. Commented 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. Commented Sep 20, 2013 at 1:29
  • 1
    I think when OP says the user "superuser", he means that literally – not root. Commented Sep 20, 2013 at 1:31

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.