Directory Permissions Defaults: Difference between revisions

From SlackWiki
Jump to navigation Jump to search
(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.