Any way to to force uid in shared directory? ACL?
 

I am setting up a machine to which several users have access via SSH and FTP.

I also have set up a user account and group to own a directory tree to which all the other users have shared access by group membership.

So far so good, works as expected.

But of course when a user, from their shell, saves a file to the shared directory, the file receives the uid of the user and gid of the group. I never thought of that as a problem.

But I have been asked by users to force all files saved in this directory to the uid of the shared directory owner instead of the login user. In other words, if 'andy' is the actual owner of the shared tree, and the group of the tree is 'thegroup', then when any member of 'thegroup' creates a file in the tree, the uid will be andy's uid.

I have looked around the net and all I find are Samba and ACL. Samba is not in the picture, so I have been reading up on ACL, but my tired brain is not really getting whether that will actually do what I want.

Has anyone done this, or know whether ACL is the right ticket?

All comments appreciated.

You could use inotify to watch for the creation of files and change the file attributes after it has been created. This is an elegant solution and will be easy on your CPU and filesystem.
See http://en.positon.org/post/A-solutio...ce-permissions for an example of how to do this.

If you find a working solution, feel free to write a bit about it on docs.slackware.com .

Eric

Thanks Eric! I was afraid I would have to go off to bed without any other suggestions.

I had thought of setting up a cron to watch it, but did not put it at the top of my list. The inotify approach looks simple enough - I'll let you know what I decide on.

Thanks for the invitation to docs.slackware.com, I'd be honored. I have hoped to become a contributor since the start, but [add excuse here...] - I'll see what I can do...

Shared directories
 

I was looking for a solution for a same kind of problem and found the solution below
Had not time to to test it yet, but post it anyway

1. Create a local user with a home directory.

2. Use the mount --bind to mount every directory you want the user have acces to the users home directory
Example :
mount --bind /path/to/shared/directory /home/user/mount/point

Repeat this for every directory tou want the user have access to
Also if you want to have the user acces to the subdirectories also, use rbind instead of bind

3. If you want the user have for example only read only rights or have other UID etc remount the file system with the proper options
For example :
mount -o remount,ro,bind /home/user1/mount/point for read only access (or rbind when using that)

If you chroot the user in his home directory , no access to other parts of the file system are possible

Inotify start script
 

Following Eric's links I was able to learn a few new things - and create a short script that allows me to do what I wanted and more!

I have written it into a single init script and am now using it on the system which started this line of thought.

Anyone interested please download, read the configuration notes to set it up, and offer improvements or comments! But this is my first time to share one of my own scripts with others, so please be kind! ;)

You can download a tarball (single file) here.

A brief description follows:

What it does

It uses inotify to monitor a directory tree for filesystem events. This makes it very efficient, not a resource hog!

When a file is created or modified within the tree, it enforces ownership by a single user and group, and sets minimum default file permission level. (I have created a special owner/user with 002 UMASK, but this is not necessary).

This allows you to set up a directory tree owned by some user and group, where all group members have r/w access, as usual. But when a group member other than the directory owner creates a file, ownership is assigned to the directory owner, not the user creating the file.

Additionally, and optionally, it will enforce a configurable minimum access permission level for all files in the tree. For example, if you specify that owner and group members have at least r/w access in the tree, ug+rw, then if an attempt is made to change any file to read only, or no access for owner or group members, it will instead be set to r/w - minimum permission level.

It also enforces a default minimum permission level for new files, but respects 'excess' permissions. For example, the new default is ug+rw,o-wx, which restricts non-group members to read only access. But if you create a file outside the watched tree and assign r-w-x to all users, then the excess x for groups will be respected, but the x for others conflicts with the minimum level of -wx and will be changed to r only.

It is set up to be run as /etc/rc.d/rc.iwatch when added to /etc/rc.d/rc.local, so it should be always on. But in the event file ownership or permissions within the tree are changed while the script is not running, it will detect and correct those when next started.

It has the usual start, stop and restart options, plus a start-fg option to start it as a foreground process for testing from a shell and receiving output for all events.

Finally, it recognizes its own watched path for start and stop conditions, and will only start or stop the inotify process using the same path. This allows you to run more than one watch scripts on different trees at the same time, but without conflict.

I am running two, each with a filename suffix which reflects its use - the example I uploaded is one of those so change or remove the suffix to meet your needs.

Give it a try and let me know what you think!