Directory Permissions Defaults: Difference between revisions
(Copy from old, had no category, placed in Tutorials) |
No edit summary |
||
(One intermediate revision by the same user not shown) | |||
Line 92: | Line 92: | ||
setfacl(1) and getfacl(1) man pages for the full story. | setfacl(1) and getfacl(1) man pages for the full story. | ||
= Official Package Data = | == Official ACL Package Data == | ||
<pre> | <pre> | ||
PACKAGE NAME: acl-2.2.39_1-i486-2 | PACKAGE NAME: acl-2.2.39_1-i486-2 | ||
Line 113: | Line 113: | ||
in slackware/a[http://packages.slackware.it/search.php?v=12.0&t=1&q=acl] | in slackware/a[http://packages.slackware.it/search.php?v=12.0&t=1&q=acl] | ||
[[User:Trashbird1240|Trashbird1240]] 14:49, 6 April 2008 (EDT) | [[User:Trashbird1240|Trashbird1240]] 14:49, 6 April 2008 (EDT) | ||
= Solution 2: SetGuid Flag = | |||
Some users are not willing (or able) to apply ACLs on filesystems. There is a way to achieve a similar ''shared'' directory effect using native Linux access controls. For example, imagine a SAMBA server with a share called ''Photos''. You need a sub-set of users on the network to be able to manage the files on the share. Additionally, you need new directories created within the share to ''inherit'' permissions from the parent. | |||
To accomplish this goal you create a group called ''mgrphotos'' and you add the users that should manage the share into that group. | |||
<pre> | |||
# Set ownership on shared folder | |||
chown -R root:mgrphotos /media/share/disk1/Photos | |||
# Set permissions on shared folder | |||
chmod -R 775 /media/share/disk1/Photos | |||
# Applying the setguid bit can allow for new files to "inherit" group membership from its parent (use this sparingly) | |||
sudo chmod g+s /media/share/disk1/Photos | |||
# Verify the setguid bit | |||
ls -all /media/share/disk1/Photos/ | grep -i family | |||
drwxrwsr-x 24 root mgrphotos 4096 2012-03-01 15:02 Family | |||
</pre> | |||
All new files created in the path are now owned by the mgrphotos group. Since this volume is mounted as 775, all members of mgrphotos share the files/folders they create on this volume. | |||
It's highly recommended that you leverage ACLs wherever possible but this is an alternate solution that works extremely well and required no extra packages or configuration. |
Latest revision as of 22:35, 19 May 2012
Problem: Sharing Directories
My wife and I keep our pictures of our kids under a shared directory called /home/shared. We download them with Digikam and sometimes edit them to send out to relatives. The problem was this: if I download the pictures off the camera, then Megan can't edit them or read them. We also had problems with shared files (e.g., our accounting spreadsheets) that I would create and she would modify, or vice versa.
Solution: ACL
To set, in effect, default file-creation masks, you can use ACL (access control lists). The user commands you need to set up ACL are getfacl(1) and setfacl(1).
Edit /etc/fstab
Edit the fourth field of the fstab entry of the partition you want to use ACL on. In this case, it was /dev/sda6 on /home:
/dev/sda6 /home ext3 defaults,acl 1 1
adding "acl" to the list of permissions. Without doing this, you'll get
setfacl: /mnt/backup Operation not supported
Then remount the partition: since I was doing this on /home, I rebooted (mount -a did not work).
ACL Commands
getfacl(1) shows you the current ACL status of a file:
/media/multimedia: Zshell> getfacl /home getfacl: Removing leading '/' from absolute path names # file: home # owner: root # group: root user::rwx group::r-x other::r-x
Once the partitions are properly set up (that was the easy part), enter the setfacl(1) commands:
sudo setfacl --recursive -dm g:users:rwx /home/shared
--recursive was important so that each directory beneath /home/shared inherits the default mask.
Now getfacl(1) gives me this:
/media/multimedia: Zshell> getfacl /home/shared getfacl: Removing leading '/' from absolute path names # file: home/shared # owner: joel # group: users user::rwx group::rwx other::r-x default:user::rwx default:group::rwx default:group:users:rwx default:mask::rwx default:other::r-x
And when creating a file:
/media/multimedia: Zshell> cd /home/shared /home/shared: Zshell> touch my_self /home/shared: Zshell> ls -l my_self -rw-rw-r--+ 1 joel users 0 2008-04-06 14:36 my_self
The desired outcome!
Note: this did what I wanted, but it's just a beginning. Read the setfacl(1) and getfacl(1) man pages for the full story.
Official ACL Package Data
PACKAGE NAME: acl-2.2.39_1-i486-2 COMPRESSED PACKAGE SIZE: 139 K UNCOMPRESSED PACKAGE SIZE: 350 K PACKAGE LOCATION: ./acl-2.2.39_1-i486-2.tgz PACKAGE DESCRIPTION: acl: acl (tools for using POSIX Access Control Lists) acl: acl: This package contains a set of tools and libraries for manipulating acl: POSIX Access Control Lists. POSIX Access Control Lists (defined in acl: POSIX 1003.1e draft standard 17) are used to define more fine-grained acl: discretionary access rights for files and directories. acl: acl: acl: acl: acl:
in slackware/a[1] Trashbird1240 14:49, 6 April 2008 (EDT)
Solution 2: SetGuid Flag
Some users are not willing (or able) to apply ACLs on filesystems. There is a way to achieve a similar shared directory effect using native Linux access controls. For example, imagine a SAMBA server with a share called Photos. You need a sub-set of users on the network to be able to manage the files on the share. Additionally, you need new directories created within the share to inherit permissions from the parent.
To accomplish this goal you create a group called mgrphotos and you add the users that should manage the share into that group.
# Set ownership on shared folder chown -R root:mgrphotos /media/share/disk1/Photos # Set permissions on shared folder chmod -R 775 /media/share/disk1/Photos # Applying the setguid bit can allow for new files to "inherit" group membership from its parent (use this sparingly) sudo chmod g+s /media/share/disk1/Photos # Verify the setguid bit ls -all /media/share/disk1/Photos/ | grep -i family drwxrwsr-x 24 root mgrphotos 4096 2012-03-01 15:02 Family
All new files created in the path are now owned by the mgrphotos group. Since this volume is mounted as 775, all members of mgrphotos share the files/folders they create on this volume.
It's highly recommended that you leverage ACLs wherever possible but this is an alternate solution that works extremely well and required no extra packages or configuration.