8

I am a non-root user, and have made a directory into which other users in my group can write. The directory is setgid, so files and directories within it have the same group.

I can delete files placed into this directory, but if a user creates a subdirectory with files in it, I can't seem to delete those. Is there something special I can do (other than, say, bothering the user in question or the sysadmin about it) to get rid of this subdirectory?

EDIT: Inevitably, of course, someone asks "why?"

The shared folder in question is a mercurial repository. We can't use a shared-account ssh-key-based server for this like mercurial-server, and we can't just host it externally for various reasons. But that part works fine. We use Redmine for project management, but it does not yet read the repo index for file contents - it reads the working directory. So the working directory must be kept up-to-date. crontab has been disabled by the sysadmin, so that's out. So I naïvely put a changeset hook in the shared repo that performed an "hg update". This seemed to work fine initially, until, of course, someone pushed a commit with a new directory. While I had vague thoughts of trying to make a setuid script for the hook, I'll probably just consider safer avenues.

Oliver Salzburg
  • 89,072
  • 65
  • 269
  • 311
kelm
  • 243

2 Answers2

4

In order to delete a file in a directory, you need to have write permission to that directory. Obviously the users are creating directories without you having write permission, in which case the answer to your question is no, you can't do anything without talking to the user in question or the sysadmin.

However, if I was the sysadmin, I would be worried about what you're doing. It is not normal for users to be creating files in other users directories. Is there a better way of doing what you're doing? For example, uploading to a suitable web application would give better control, and also mean that you don't have to worry about this.

gorilla
  • 2,320
0

This is not a fool proof answer, because users can override the umask, but you can set the umask of your "public" folder to be inherited by other users, so that any directory they make will have 777 permission too. That will let you delete their files.

dir=/tmp/abcd
mkdir -o $dir
chmod 777 $dir
setfacl -d -m o::rwx $dir
setfacl -d -m g::rwx $dir

# let users write to $dir, including making subdirs underneath
# examples:
sudo -u other_guy mkdir -o $dir/foo
sudo -u other_guy touch $dir/foo/bar

rm -rf $dir

Without the setfacl lines, this won't work, because $dir/foo/bar can be deleted by anyone besides other_guy.

This breaks, of course, if the user decides to purposely change the permissions of files.

Mark Lakata
  • 9,588