How do I give a user permission to use the rm command, but only within a certain directory? I tried adding this to my /etc/sudoers file

myuser ALL = NOPASSWD : /bin/rm ???? /usr/java/jboss/standalone/vfs/*

but when I'm lgoged in as that user, and execute the commmand

/bin/find $JBOSS_HOME/standalone/tmp/vfs -mindepth 1 -mmin +1441 -exec sudo rm -rf {} \;

I get prompted for a password

[sudo] password for myuser:

What else do I need to change to get this to wokr properly?

  • sudo rm -rf /usr/java/jboss/standalone/vfs/../../../../../bin – roaima Mar 9 '17 at 22:01
  • rm != /bin/rm. – Kusalananda Mar 10 '17 at 9:50

You have 'stalone' in your sudoers and 'standalone' in your find command. That might be the issue.

  • Thans. I changed the line (and updated my quesiton) but I still get prmopted for the password. – Dave Mar 9 '17 at 21:25
  • "? Matches any single character (including white space)." Replace ???? (four characters exactly) with -*. I do not guarantee this is secure. – sourcejedi Mar 9 '17 at 21:54
  • I agree with sourcejedi. This is not an ideal use for sudo. The user should already have access to the rm command. It would be better to put the user in a group that has permissions to the folder and files underneath. Then the user could remove the files. This is giving the user access to rm the files as root. – feeble Mar 9 '17 at 22:01

Remember that with this sudo command a /bin/rm -rf /usr/java/jboss/standalone/vfs/file /something_other_might_be_whole_filesystem is also permitted (similar what roaima stated in comment).

If you have to do this that way I would suggest putting whole find command under sudoers as there are no wildcards.

Possibly much better solution would be to change ownership of directory or putting myuser in group that has write access to mentioned directory.


As others have already noted, your command allows the user to delete and directory tree on the system. To give a user the permission to delete files in a specific directory, you would need to write a wrapper script. In the sudoers file:

myuser ALL = NOPASSWD: /usr/local/sbin/rm_jboss_vfs

In /usr/local/sbin/rm_jboss_vfs:

for x do
  case "$x" in
    */../*|*/..) echo >&2 "$0: .. forbidden"; exit 3;;
    /usr/java/jboss/standalone/vfs/[!.]*) rm -rf -- "$x";;
    *) echo >&2 "$0: only absolute paths under /usr/java/jboss/standalone/vfs are permitted"; exit 3;;

Note that the user can still escape /usr/java/jboss/standalone/vfs if there are symbolic links there. A safer approach would be to chroot into the directory. Use a shell with the rm command built in, such as sash.

set -e
-chroot /usr/java/jboss/standalone/vfs
for x do
  case "$x" in
    /usr/java/jboss/standalone/vfs/[!.]*) -rm -rf -- "$x";;
    *) echo >&2 "$0: only absolute paths under /usr/java/jboss/standalone/vfs are permitted"; exit 3;;

The issue with the password prompt is probably due to the presence of another entry in the file that allows the user to run this command with a password prompt. If two entries match, sudo uses the last one, so put any NOPASSWD: entry last. See How to run a specific program as root without a password prompt?

Instead of using privilege elevation, it would be better give the user the permission to do what they need. Unix permissions are too coarse-grained for that: giving a user permission to remove files in a directory requires giving them write permission to the directory (so in particular the permission to create files there). At least, instead of running the deletion script as root, run it as some group jboss_vfs_deleters and give that group the permission to write to the directories in question. Set the directory permissions:

setfacl -d -R -m group:jboss_vfs_deleters:rwX /usr/java/jboss/standalone/vfs
setfacl -R -m group:jboss_vfs_deleters:rwX /usr/java/jboss/standalone/vfs

In the sudoers file:

myuser ALL = (jboss_vfs_deleters) NOPASSWD: /usr/local/sbin/rm_jboss_vfs

Run sudo -g jboss_vfs_deleters /usr/local/sbin/rm_jboss_vfs … (you can hide that in an unprivileged wrapper script).

The downside of using a group is that you can no longer use chroot, you have to use the less robust named-based filtering approach.

Note that files under /usr are not supposed to be modified during normal operation. I don't know what those files are, but if you're modifying them in normal operation they should probably be under /var.

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.