Deploying Suse Linux Enterprise Server


Purchase "Deploying Suse Linux Enterprise Server"
at Lulu.com

File & Directory Permissions on Linux

Working with Permissions

Now that you should have the basics of file permissions down, this section includes some "tips and tricks" that I use to ensure that permissions are properly set on servers.

Home Directories

Most admins overlook the setting of permissions on user's home directories. I believe, this is because most admins do not have a good understanding of Unix Permissions (especially those coming from a Windows background). Because of this, most Linux Servers are deployed with the default permissions in place, which are the owner has full permissions and everyone else has read permissions. This may not be what you want (everyone has the ability to read everyone else's files), and you should seriously look at home directory permissions before deploying any servers.

To fully understand what you can accomplish with home directories I am going to give an example that I used when deploying SLES at a local high school:

First, in order to maintain some sort of organization, the school decided to separate out the home folders into the student's graduation year. So within the "/home" directory, there were directories "2008", "2009", "2010", "2011", etc. for all of the student's home directories. There were also directories called "teachers", "staff" and "admins" to hold all of the staff's home directories.

Using separate containing directories for the user's home directories proved to be quite successful not only for organization purposes, but also to ensure that correct file permissions were enabled. For every student's home directory we adjusted the permissions to have the group ownership of the "teachers" group and we ensured that the teachers could write to the folders. We also ensured that the other students had no access to other student's files. For instance, to set permissions we ran:

cd 2009
chgrp teachers * -R
chmod g+w * -R
chmod g+s * -R
chmod o-rwx * -R

This ensured that the teachers had write permissions to the student's files, while ensuring that any new file that was created by the student had the "teacher" group as the group owner (using the setgid bit). We did this for all of the student's folders as well as all of the staff's folders (except we changed the group ownership to "sadmins" (Super Admins) instead of "teachers" for the staff).

Note: We did run into one problem when implementing this. If a user logged into a Suse Linux workstation a permissions error appeared upon login. To fix this error we simply had to manually change the permissions of the ~/.dmrc file to 0644 to fix the error. (See the script below)

Scripting File Permissions

Once you have a deployment strategy for file permissions, you may want to create a shell script to apply those permissions. This alleviates manually running a group of commands after you create a new user or when the permissions are not correct (which occasionally happens when "copying" files).

Using the above example of the school, here is a shell script that is ran as a daily cron job to ensure the permissions are correct:

#!/bin/bash

# This script will reset permission's on home directories every night

cd /home

# First we will reset the permissions for the Student Folders.
# We store all of the students folders within their graduation year
# This makes it easy to sort the student's data

# The first loop changes into the student's graduation year directory

for grad_dirs in $(ls 20* -d); do
	cd $grad_dirs

# This next loop actually changes permission on all the student's files
#  and directories.

	for userlogin in $(ls); do
		cd $userlogin
		find -type d -exec chmod 2775 '{}' \;
		find -type f -exec chmod 664 '{}' \;
		install -m 0644 /var/defaults/.dmrc ./
		cd ..
		chown $userlogin $userlogin -R
	done

# Finally, while we are still in the grad year directory, we change group
#  ownership of all the files and directories to the teachers. This allows
#  them full access to the students files and folders.  Before we exit the
#  graduation year directory we also remove "others" access to the student's
#  directory - this ensures students can't access other students data.

	chgrp teachers * -R 
	chmod 2750 *
	cd ..
done

# Now we will do the same thing for the Teachers and Staff Accounts, the
#  difference will be the group owner will be sadmins (Super Admins) instead
#  of teachers.  This will allow Teachers and Staff to store private data
#  in their home directories, while allowing Administrators to monitor their
#  disk usage and ensure no copyright material is stored on school property.
for staff_accounts in staff teachers
do
        cd $staff_accounts
        # Run the same loop as the student dirs above
        for userlogin in $(ls); do
                cd $userlogin
                find -type d -exec chmod 2775 '{}' \;
                find -type f -exec chmod 664 '{}' \;
		install -m 0644 /var/defaults/.dmrc ./
                cd ..
                chown $userlogin $userlogin -R
        done

        chgrp sadmins * -R
        chmod 2750 *
        cd ..
done

As you can see in the above example it can be easy to ensure correct permissions are maintained on your shares. Another thing to note in the above example is the procedure used to change the permissions of items depending upon whether they are files or directories (since these two entities have different permissions - i.e. directories should be executable). So, if you copy files from a CD or another server, to ensure the permissions are "Unix Compatible" run something similar to:

cd directory
find -type d -exec chmod 755 '{}' \;
find -type f -exec chmod 644 '{}' \;

A Basic Network Share

Now I will put all this together and show how to create a network share that is fully accessed by members of the "company" group:

mkdir /srv/exports/share

chgrp company /srv/exports/share
chmod g+w /srv/exports/share
chmod o-rwx /srv/exports/share

cp /old/files/* /srv/exports/share -f -r
cd /srv/exports/share

chgrp company * -R
find -type d -exec chmod 2770 '{}' \;
find -type f -exec chmod 660 '{}' \;

Once that is done, if the share is accessed using NFS on Linux workstations, ensure the umask on those workstations is set to 002 or 007 (to ensure the "Group" has write access on new files), and if the share is accessed on Windows workstations, ensure the appropriate "masks" are set in the Samba Share definition.

Access Control Lists

Although basic file permissions will probably work for nearly all of your file share deployments, occasionally you might need the ability to "fine-tune" permissions for some network shares or files. You can accomplish this control by using Access Control Lists (ACLs) on your files and directories.

For this tutorial, I am not going to go into detail regarding ACLs. Although, it is easy to adjust and add ACLs from Linux using either the Konquerer file manager or the Nautilus file manager (with the eiciel plugin). You can even adjust ACLs using Windows Explorer (from remote Windows Workstations connecting through Samba). However, a word of warning is important: Not all GNU/Linux applications properly support ACLs (yet), if you deploy ACLs on Directories / Files accessed through NFS using SLED or another GNU/Linux Distribution, ensure that all of the apps that will access these shares properly support ACLs.

Finishing Up

Hopefully, after reading this you have a better understanding of Permissions within a GNU/Linux system. Once you develop a deployment plan, I highly recommend creating a script to ensure proper permissions are maintained on your servers. Linux file permissions may look too simplistic at first glance, but once you grasp the concept you will quickly see the ingenuity (and the power) behind them.



Next


Purchase "Deploying Suse Linux Enterprise Server"
at Lulu.com