Group directory challenge

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

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.

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.

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.

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.

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.