4

How can I create directories so:

/data
/data/user1
/data/user2

and make sure that whenever root writes inside them, depending on which directory it writes to, different owners are set.

Example:

  1. Root writes to /data -> normal file creation
  2. Root writes to /data/user1 -> any files created therein are automatically owned by user1 and readable by others (the same should apply if user1 writes to the dir himself)
3

The script below can be pretty dangerous, and only monitor new files created in ${DIR}, owner of any file created will be changed to ${OWNER}, and add global read permission.

Use it at your own risk ...

#!/bin/bash

DIR="$PWD/user1"
OWNER="user1"

inotifywait -m --format "%e %f" "$DIR" | awk '$1 ~ "CREATE" { print $2; fflush() }' | 
while read file
do
    FILE="${DIR}"/"${file}"
    echo "Changin permission for ${FILE}"
    chown user1 "${FILE}"
    chmod o+r "${FILE}"
done

It would be more secure if you wrote a fs driver and mount it.

1
  • What are $1 and $2 supposed to be? Can you provide an example of how it is executed? Also, shouldn't it be chown $OWNER "${FILE}" ?
    – frakman1
    Oct 31 '19 at 20:39
3

You can get something close to what you want using the SGID bit on the directories. If you run

chmod g+s /data/user1

Then any file or directory created in that directory will have the group ownership set to be the same group as that of the directory itself. It doesn't achieve precisely what you want but it gets you part of the way there.

Another way to do this is to use POSIX acls and set default acls on the directories. Default acls will be inherited by files created in the directories. They don't change ownership but they do offer a way to give read, write or execute access to arbitrary groups beyond the three basic groups of standard file acls.

7
  • 1
    To whomever tried to edit this: I knocked your edit back because a) you mis-corrected extended acls to file acls and b) you added a recommendation for SuSE which I did not make. On the first point, you are factually incorrect: file acls can mean just the basic POSIX three-octet acls, where the funcionality I'm describing is only available through extended acls. On the second point, adding your own recommendation to my answer is simply unacceptable. Add your own answer if you want to make new recommendations.
    – itsbruce
    Oct 18 '12 at 7:16
  • 1
    SE is a collaborative place, to quote the FAQ, If you are not comfortable with the idea of your contributions being collaboratively edited by other trusted users, this may not be the site for you. Those ACLs are referred to "file ACLs" or sometimes improperly POSIX ACLs throughout the documentation and are basic compared to the more extended NFSv4 ACLs or Rich ACLs or ZFS ACLs, so calling them extended is misleading. Unix persmissions are called unix permissions, not ACLs. Oct 18 '12 at 9:50
  • Fair enough about the acls and I didn't mean to sound confrontational. But I don't think it's a good thing to add whole new recommendations to a different user's answer, just as a matter of policy. Personally, I would only mention RichACLs with very heavy caveats.
    – itsbruce
    Oct 18 '12 at 10:02
  • Just to clarify. My first motivation for editing it was the very confusing (at least to me) "extended ACL" term which I wasn't sure was refering to the POSIX1e draft 17 ACLs implemented by a few Unices like Linux, or the Standard (RFC 3530) NFSv4 ACLs implemented by a few Unices (BSDs, Solaris on ZFS at least) though only available as a patch for Linux (which OpenSuse is the only distribution that I know ships with). I don't use or recommend OpenSuse, I just brought RichACLs up here to clarify the distinction between the two variants of ACLs. Oct 19 '12 at 11:27
1

bindfs may do the trick for you

cd /data
chown user1:user1 user1
bindfs --create-for-user=user1 --create-for-group=user1 --create-with-perms=go+rD user1 user1

See the rest of bindfs man page for more things like chown/chmod policies.

2
  • This would be the appropriate place to add your mention of RichACLs.
    – itsbruce
    Oct 18 '12 at 7:25
  • 1
    @itsbruce, no. ACLs don't belong in this answer, more in the permission and ACL answer (nice answer which I upvoted and tried to improve) that you created. Oct 18 '12 at 9:52
-1

You can't.

That's a job for either:

  1. cron & chown
  2. inotify & some scripting on your side.

Personally I'd go w/ inotify. The script above is a good starting point.

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.