I understand the concept of managing permissions on Linux with chmod using the first digit as the user, the second as the group and the third as other users as described on this answer in Understanding UNIX permissions and file types.

Let's say I have a Linux system with 5 users: admin, usera, userb, userc and guest. By default, the users usera, userb and userc will have execution permission on all files inside /usr/bin, so these users can use the command line of the system executing the files in there as those files have 755 permission. So far it's completely ok. However, I'd like to forbid the user guest from executing files on the folder /usr/bin, I know I could achieve that by changing the permission of all files inside this folder to something like 750 with chmod, but if I do that I'll mess up the permissions of the users usera, userb and userc because they will be also forbidden to execute files.

On my computer, all the files in /usr/bin belong to the group root, so I know I could create a newgroup, change the group of all those files to it and add usera, userb and userc to newgroup. But doing that sounds like way too much modification on the system's default settings. Does anyone know a smarter way of solving this problem?

How can I forbid a single user from using the command line (or executing any file on PATH) without an overcomplicated solution that requires changing the permissions of too many files?

  • 1
    @planetmaker no! You'll either break the entire system or else break distribution upgrades.
    – roaima
    Mar 5, 2020 at 7:49
  • 4
    That implies user guest won't even have a shell to start, because /usr/bin and /bin are identical in many modern distros. (My gut feeling would be to try and put them in a chroot jail; it's possible that systemd even gives you nice automatisms for that, like it does for services.) Mar 5, 2020 at 8:42
  • 3
    I'd implement this with a PAM module that does a bind mount of /var/empty over /usr/bin in a private filesystem namespace during login for the relevant user. Why do something that modifies the filesystem for everyone, when you can modify the filesystem only for the one user? Mar 5, 2020 at 17:38
  • 1
    See ibm.com/developerworks/library/l-mount-namespaces/index.html discussing a (different) private-namespace PAM module's implementation. Mar 5, 2020 at 17:40
  • 3
    Just a heads up, but permissions are defined with 4 octal digits, not 3. You might be thinking that all your files are 755, but I have many that are 4755, 2755, 6755, etc. 750 is the same as 0750, so by changing them all to 750, you might be breaking quite a few executables (like sudo) by clearing their suid, sgid, and sticky bits.
    – JoL
    Mar 5, 2020 at 20:02

2 Answers 2


Use ACLs to remove the permissions. In this case, you don't need to modify the permissions of all the executables; just remove the execute permission from /usr/bin/ to disallow traversal of that directory and therefore access of any files within.

setfacl -m u:guest:r /usr/bin

This sets the permissions of user guest to just read for the directory /usr/bin, so they can ls that directory but not access anything within.

You could also just remove all permissions:

setfacl -m u:guest:- /usr/bin
  • 5
    This will potentially break all distribution upgrades. It's a really bad idea.
    – roaima
    Mar 5, 2020 at 7:49
  • 5
    why? from the command above only the user guest would be affected or am I missing something?
    Mar 5, 2020 at 8:54
  • 9
    @roaima: Explain please.
    – Joshua
    Mar 5, 2020 at 16:24
  • 4
    If nothing else, it'll break when whatever your OS's equivalent to the filesystem package is gets reinstalled and tries to reassert the original permissions. Mar 5, 2020 at 17:38
  • @Charles I don't that that checks ACLs.
    – muru
    Mar 6, 2020 at 1:20

What are you trying to do? Forbidding use of the system's standard commands to some user is just incivil behavior in the extreme... commands that could put the system in jeopardy are far in between, and have been carefully vetted for security. The permissions on files should stop most attempts at mischief.

  • Consider giving them a restricted shell (check the manuals, it is probably named something like rbash; careful though, rsh is a different kind of animal!). They cage the user rather effectively (but watch out, it is possible to break out!)
  • If this is a pseudo-user in charge of owning some service, the common way out is to give the "user" a shell that does nothing, like /bin/true (check your system's manual for any recommendations in this line, there might be a special program for this; if /bin/true is a shell script don't use it for this). That way, if somebody manages to log in to that account, their session finishes immediately.
  • Create a chrootfor them (again, there are ways to break out), or use Linux' containers of BSD's jails to confine them, and just expose exactly what you want them to see. Most control, but messy to set up and keep up to date.
  • Forbidding use of the system's standard commands to users is not uncivil behavior, everything depends on the context of how it's being used, even the act of deleting a user could be seen as uncivil behavior if used by the wrong person. But as I wrote in the comments of my question, I'm giving ssh access to the user guest just so he can port forward the system to have access to specific web applications. A "caged" shell wouldn't be the ideal solution to my case because it'd still allow the user to use RAM memory and CPU power with scripts. But thanks for bringing a different perspective. Mar 5, 2020 at 22:28
  • 3
    @RafaelMuynarsk if you want to limit the user to port forwarding and nothing else, you may want an SSH "Forced Command", see this question and/or google for "ssh forced command" (you may not even need a separate user!)
    – Josh
    Mar 5, 2020 at 22:31
  • 1
    @Josh That's actually exactly what I needed. I haven't thought I could create these restrictions directly on my SSH configuration. Thanks! Mar 5, 2020 at 22:40
  • Sure thing! Yeah I didn't know about forced commands for years, they're an amazing feature (especially for running specific commands remotely as root or other privileged users)
    – Josh
    Mar 5, 2020 at 22:45

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.