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)
daisy
  • 54,555
Robottinosino
  • 5,321

4 Answers4

4

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.

itsbruce
  • 1,794
  • 1
  • 10
  • 12
  • 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 07: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. – Stéphane Chazelas Oct 18 '12 at 09: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
  • @sch http://meta.stackexchange.com/questions/151940/misleading-improve-this-question-link-producing-many-invalid-edits – itsbruce Oct 19 '12 at 10:53
  • 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. – Stéphane Chazelas Oct 19 '12 at 11:27
  • I get all that :) I just thought you might be interested that there's a discussion happening on meta (which I did not start) about this. We can talk about it there without adding any more noise to this question ;) – itsbruce Oct 19 '12 at 11:30
  • I see you've added "standard file ACLs" which is even more confusing to me now given that I've never seen Unix permissions referred to as ACLs. The only file ACLs that have ever been covered by a standard (to my knowledge) as I said are the NFSv4 ACLs. – Stéphane Chazelas Oct 19 '12 at 11:30
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.

daisy
  • 54,555
  • 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}" ? – Frak Oct 31 '19 at 20:39
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.

Stéphane Chazelas
  • 544,893
-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.

tink
  • 6,765