2

Have a challenging question for you. Have a linux box. Need to create directory where users would be able to create files, but remove/modify only files created by them. Simple enough to have sticky bit set and thats it. But then we want particular admin user to be able to remove files from this directory and not being root user. How to do that? NFS4_ACLs are possible there. But I'm sure they won't help. Ideas? Users: user1:uploaders user2:uploaders admin1:admins <--- should be able to manage files in group dir

sgid on dir makes it possible to protect files from being edited by other users, but nothing stops user from deleting other users' files. Thats the problem

UPDATE 1:

The question was for FS permissions and nfs4_acls just because the users would be working with files over sftp. So that sudo and other scripted ways are not possible. Possible is to use LD_PRELOAD for sftp-server and override the unlink syscall or something like that. So it falls in to openssh and sftp-server.

UPDATE 2:

The users are chrooted to the directory in question by openssh and the directory should be root:root owned for it to work. All the files are put in this directory without any structure (app specific). The admin is actually not the only user to manage uploaded files but rather a group of admin users.

  • 1
    You mention NFS4_ACLs, is this directory intended to be created in a NFS share? – dawud Mar 30 '15 at 21:19
  • @dawud the directory is stored on NFS4 share which is good because it allows me to use NFS4_ACLs which are quite powerful – Dmytro Leonenko Apr 6 '15 at 16:03
  • Sorry that I haven't been answering there for a long time – Dmytro Leonenko Apr 6 '15 at 16:04
  • On a linux nfs server nfs4 acls are basically transposed onto posix acls on the local filesystem. For which the setuid bit takes precendence over the posix ACL, using ACL's looks like a non-starter. – Matthew Ife Apr 8 '15 at 19:25
  • The best way I can think of to acheive this is with a fuse program to perform a custom management layer. If you wanted that it would be for money not points! Alternatively you can possibly come up with a way by using pubkeys for the 'managers' to be able to login as any allowed user through the 'SSHAuthorizedKeys' command to call a special script. But that might become difficult to manage for many users and admins. – Matthew Ife Apr 8 '15 at 19:37
1

I'd be inclined to solve with with sudo rather than with ACLs. (There's no explicit mention of NFS in the question so I'm going to assume that root_squash isn't an issue.)

Start with your directory having permissions 1777 (sticky plus all read/write) as you suggested.

Create this script with a filename such as /usr/local/bin/rmd. Amend the definition of TARGET so that it is the absolute path to the target directory

#!/bin/bash
#
# Remove files from $TARGET. Some care is taken to avoid escaping from
# the path root
#
########################################################################
#
TARGET='/tmp'

ERROR=
for ITEM in "$@"
do
    LINK=$(readlink -f "$ITEM")
    if test -n "$LINK" && echo "$LINK" | grep -vq "^$TARGET/"
    then
        echo "Suspicious path: $ITEM" >&2
        ERROR=yes
    fi
done
test yes = "$ERROR" && exit 1

exec rm "$@"

Add the following entry to the sudoers file (use visudo to edit this file). Change the admin to be the user with administrative privileges to delete files in the target directory.

admin ALL = NOPASSWD: /usr/local/bin/rmd

Since we know that rmd is in /usr/local/bin it would be possible to re-exec the script if it didn't have sufficient privileges, and so avoid the administrative user having to remember to use sudo, but I've omitted that for now. Let me know if you want this adjustment to the script.

Usage example

$ ls -l /tmp
lrwxrwxrwx 1 roaima roaima 4 Mar 31 00:17 etc -> /etc
-rw-r--r-- 1 roaima roaima 0 Mar 31 00:29 one
lrwxrwxrwx 1 roaima roaima 2 Mar 31 00:20 root -> ..
-rw-r--r-- 1 roaima roaima 0 Mar 31 00:29 two

$ sudo rmd /tmp/etc/hosts /tmp/root/etc/motd /tmp/one
Suspicious path: /tmp/etc/hosts
Suspicious path: /tmp/root/etc/motd

$ ls /tmp
etc  one  root  two

$ sudo rmd /tmp/one /tmp/root
$ ls /tmp
etc  two
  • This can't be solution because it won't work over SFTP while regular FS permission would. Its more like a workaround which is fine in some cases but not in this case – Dmytro Leonenko Apr 6 '15 at 15:48
  • @Dmytro Why won't the sudo rmd approach work in the general case? Subsequent to your updates, ignore the directory permissions I originally suggested and reapply the proposed solution. I still think it has merit and I will quite happily work on its detail, but I need to understand why you think it's a non-starter, please. – roaima Apr 8 '15 at 20:42
  • How do ine use sudo script from sftp/scp client? – Dmytro Leonenko Apr 9 '15 at 10:04
  • @Dmytro, your admin users also access this share via sftp? Where in your Question does it say that? – roaima Apr 9 '15 at 15:34
  • all users are accessing the server using sftp/scp – Dmytro Leonenko Apr 15 '15 at 7:16
0

Bindfs is one possible solution. I named my power admin user nradmin and here is the example:

mkdir /uploads
chmod 1777 /uploads

mkdir /home/nradmin/manage-uploads
bindfs -u nradmin -p ud+rwx /uploads /home/nradmin/manage-uploads

Every file and directory in the mounted target is owned by nradmin. The -p ud+rwx makes every directory to be with permissions "rwx" for the directory owner. Since nradmin is the owner of all directories and it has full owner permissions in them, it can successfully delete any file in them, even recursively.


The alternative approach would be that you code a limited chroot() implementation of /bin/rm and execute it as root. A chroot() can be escaped by a process ran by root but only if you give this process the freedom to execute whatever it wants. A simple C binary which first makes chdir() & chroot() to the /uploads directory, and then only calls unlink() or rmdir() should be secure. But this requires lots of coding like recursive delete of directories, a command-line option like -f to ignore non-existing files, etc.

  • I need a group of users to be able to remove files. Not only one adnin – Dmytro Leonenko Apr 6 '15 at 15:54
  • If you don't have dozens of admin users, you can do a bindfs mount in each of their home directory and manage it via sftp. – famzah Apr 6 '15 at 19:24
  • admin users are chrooted as well, but one layer higher than uploaders. All of this falls within DocumentRoot of webserver. They are more like a media managers who manage not only these files. – Dmytro Leonenko Apr 7 '15 at 6:32
0

One simple solution appears to be this. Consider the administrative user to be admin, and that our special directory is to be /tmp/special.

mkdir /tmp/special
chmod 1777 /tmp/special
chown admin:admin /tmp/special
ls -ld /tmp/special
drwxrwxrwt 2 admin admin 4096 Apr  3 21:34 /tmp/special

Any user can create/edit/delete their own files in /tmp/special. The user admin can delete any file (albeit with warnings from rm).

NB If a user creates a directory in /tmp/special, the administrative user cannot remove it. That may be a showstopper for this solution, but as your question only mentioned files and not directories I felt it was worth offering.

  • Your answer could have been a solution actually but I'm stick with root:root on directory because this dir is used as chroot for sftp user thus has to have root:root ownership. There are only files to be uploaded, but.... – Dmytro Leonenko Apr 6 '15 at 15:58
0

The full scope of this problem is unclear as we do not know what's the usecase. However using SELinux labels one get achieve what you ask for. SELinux gives you some fine-grained controls over who does what and where. If number of users is "limited" and "known" - having specific contexts/labels associated with each one of them is not a big issue, then it is a matter of writing a bit of policy to code-in your requirements.

  • It is to be done on Ubuntu box mounting remote NFS4 FS. On the back is OpenIndiana server. – Dmytro Leonenko Apr 6 '15 at 15:56
0

Hmm... how about chrooting to /special_folders_root/special_folder/./ to avoid problems with root-owned chrooted directories? See vsftpd's documentation (for example) for explanation about extraneous dot in the path.

Unsure, if following will be useful, but: We have samba share with subdirs. Network MFUs putting the scanned documents inside specific subdirs (MFU01 --> /share/001/, MFU15--> /share/015/ etc). Users (from windows) may alter or remove the files in any of these subdirs, but can not remove the subdirs. I made that using windows-style ACLs, but I know nothing about NFS ACLs

NB! Not for bounty, but for assistance.

  • there is no FTP at all. it is sftp. – Dmytro Leonenko Apr 9 '15 at 10:02
  • А какая разница? – Troublemaker-DV Apr 9 '15 at 11:19
  • The difference is that using sftp-server user can only be chrooted in root owned directory – Dmytro Leonenko Apr 10 '15 at 22:07
  • It's OK. Root can be owner, but the trick with extra dot allows non-anonymous user to do what he need. This dot designates chroot point, and if there's something after it, like blablabla/./abyrwalg, then user's root will be root-owned blablabla, but his starting position will be abyrwalg directory, which is not required to be root-owned. – Troublemaker-DV Apr 11 '15 at 2:30
  • did you try this with sftp-server? – Dmytro Leonenko Apr 15 '15 at 7:17
0

How about this approach:

Keep original uploaded files in a separate directory, per user. This covers governance and delete permissions.

In $share, everything is a link to the original files, and owner/admin ACLs are in place.

In the end, every item in $share is a link back. Anything that isn't a link gets moved to the (uploader) owner's folder.

  • See update2: All the files are put in this directory without any structure (app specific). – Dmytro Leonenko Apr 9 '15 at 10:00
  • What user does is only upload file and thats all. – Dmytro Leonenko Apr 9 '15 at 10:01

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.