Linux File Permissions, Groups, and Users

Why Are Permissions Important?

Permissions are important for keeping your data safe and secure.   Utilizing permission settings in Linux can benefit you and those you want to give access to your files and you don’t need to open up everything just to share one file or directory (something Windows sharing often does).  You can group individual users together and change permissions on folders (called directories in Linux) and files and you don’t have to be in the same OU or workgroup or be part of a domain for them to access those files.  You can change permissions on one file and share that out to a single group or multiple groups.  Fine grained security over your files places you in the driver seat in control of your own data.

Some will argue that it may be too much responsibility…that placing this onto the user is foolish and other aforementioned operating systems don’t do this.  You’d be right…XP doesn’t do this.  However, Microsoft saw what Linux and Unix do with the principle of least privilege and have copied this aspect from them.  While the NTFS filesystem employs user access lists with workgroups and domains…it cannot mirror the fine grained, small scale security of Linux for individual files and folders.  For the home user, Linux empowers control and security.

I’m going to go over how users and directory/file permissions work.  So, let’s setup an example that will allow us to explore file permissions.  If you have any questions, just ask it in the comments section at the end of the article.

File Permissions Explained

permissionsThe picture to your left is a snapshot of my $HOME directory.  I’ve included this “legend” to color code and label the various columns.  Let’s go through the labels and names of things first and then work on understanding how we can manipulate them in the next section.

As noted in the picture, the first column (orange) explains whether or not the contents listed is a directory or not.  If any of these happened NOT to be a directory, a dash (-) would be in place of the d at the beginning of the listing on the far left.

In the second, third, and fourth column (Green, Blue and Red) we find permissions.  Looking at the gray box in the bottom-right corner gives us an explanation of what each letter represents in our first few columns.  These tell us whether or not each user, group, or other (explained in detail later in this article) have read, write, and execute privileges for the file or folder/directory.

In the 5th column (white) the number of hard links is displayed.  This column shows the number of actual physical hard links.  A hard link is a directory reference, or pointer, to a file on a storage volume that is a specific location of physical data.  More information on hard links vs. symbolic (soft) links can be found here.

In column 6 (light blue) we find the user/owner of the file/directory.  In column 7 (gray blue), the group that has access to the file/folder is displayed.  In column 8 (pink), the size of the file or folder is shown in kilobytes.  In column 9 (fluorescent green), the last date the file or folder was altered or touched is shown.  In column 10 (grey), the file or directory name is displayed.

We’re going to pay specific attention to the first four columns in the next section and then follow that up by working with the sixth and seventh by going over user/owner and group.  Let’s move on to go over all of those rwx listings and how we can make them work for us.

Read, Write, Execute – User, Group, Other

First, let’s go over what different permissions mean.  Read permission means you can view the contents of a file or folder.  Write permission means you can write to a file or to a directory (add new files, new subdirectories) or modify a file or directory.  Execute permission means that you can change to a directory and execute ( or run ) a file or script for that file or directory.

The User section shown in green in the picture above shows whether or not the user can perform the actions listed above.  If the letter is present, the user has the ability to perform that action.  The same is true for the Group shown in blue above…if a member of the group that has access to the file or directory looks in this column, they will know what they can or can’t do (read,write, or execute).  Lastly, all others (noted in the red column above).  Do all others have read, write, and execute permissions on the file or folder?  This is important for giving anonymous users access to files in a file server or web server environment.

You can see how fine grained you might be able to set things up with…For example, you may give users read only access while allowing a group of 5 users full control of the file or directory.  You may want to switch that around.  It’s entirely up to you how you want to setup permissions.

More about Groups

Let’s go through setting up a group and adding a few users to it and then assigning that group permissions to access a directory and file.

Create a file inside your home directory by opening up a shell or terminal and typing:

touch ~/example.txt

You’ve now created a file called example.txt inside your home directory.  If you are already there, you can list the contents with the ‘ls’ command.  Do that now.  If you’re not already there, type ‘cd ~/’ and you will be taken to your home directory where you can ‘ls’ list the files.  It should look similar to the following:

[devnet@lostlap ~]$ ls -l
total 40
drwxr-xr-x  2 devnet devnet 4096 2010-05-24 17:04 Desktop
drwxr-xr-x  6 devnet devnet 4096 2010-05-24 13:10 Documents
drwxr-xr-x  9 devnet devnet 4096 2010-05-27 15:25 Download
-rw-rw-r--  1 devnet devnet    0 2010-05-28 10:21 example.txt
drwxr-xr-x 13 devnet devnet 4096 2010-05-26 16:48 Music
drwxr-xr-x  3 devnet devnet 4096 2010-05-24 13:09 Pictures
drwxr-xr-x  3 devnet devnet 4096 2010-05-24 13:04 Videos

Next up, let’s create a new group and a couple of new users.  After creating these we’ll assign the users to the new group.  After that, we’ll move the file and lock it down to the new group only.  If everything works as planned, the file should be accessible to root and the other 2 users but NOT accessible to your current user. You’ll need to be root for all of these commands (or use sudo for them). Since I have sudo and don’t want to continually type sudo, I used the command “sudo -s” and entered my root password to permanently log in as root in a terminal for the duration of this how-to. OK, Let’s get started:

[root@lostlap ~]$ useradd -m -g users -G audio,lp,optical,storage,video,wheel,games,power -s /bin/bash testuser1
[root@lostlap ~]$ useradd -m -g users -G audio,lp,optical,storage,video,wheel,games,power -s /bin/bash testuser2

The above commands will create two users that should be pretty close to your current logged in user (as far as group membership goes).  If the groups you’re adding the user to do not exist, you may get a warning that the groups don’t exist…no worries, just continue.  If the above commands don’t work on your system (I used Arch Linux to do this) then you can use the GUI elements to manage users and add a new one.  You won’t need to add them to any extra groups since we just need a basic user.  Next, let’s create our ‘control’ group.

[root@lostlap ~]$ groupadd testgroup

The above command creates the ‘testgroup’ group. Now let’s add the two users we created to this group.

[root@lostlap ~]$ gpasswd -a testuser1 testgroup
[root@lostlap ~]$ gpasswd -a testuser2 testgroup

The command above adds both our test users to the test group we created. Now we need to lock the file down so that only those users inside of ‘testgroup’ can access it. Since your current logged in user is NOT a member of ‘testgroup’ then you shouldn’t be able to access the file once we lock access to that group.

[root@lostlap ~]$ chgrp testgroup example.txt

The above command changes the group portion of file permission (discussed earlier) from a group your currently logged in user is a member of to our new group ‘testgroup’. We still need to change the owner of the file so a new terminal opened up as your current user won’t be the owner of example.txt.  To do this, let’s assign example.txt a new owner of Testuser2.

[root@lostlap ~]$ chown testuser2 example.txt

Now when you try to access the file example.txt you won’t be able to open it up as your standard user (root still will be able to access it) because you don’t have the permissions to do so. To test this, open up a new terminal (one where you are not root user) and use your favorite text editor and try to open up example.txt.

[devnet@lostlap ~]$ nano example.txt

Both testuser1 and testuser2 will be able to access example.txt because testuser2 owns the file and testuser1 is in the testgroup that has access to this file. However, your current logged in user will also have READ rights to it but will not be able to access it. Why? Let’s take a look at the permissions on example.txt

[devnet@lostlap ~]$ ls -l example.txt
-rw-r--r-- 1 testuser1 testgroup 8 2010-05-28 10:21 example.txt

Notice that the user, group, and other (1st, 2nd, and 3rd position of r,w,x – see the handy diagram I made above) have permissions assigned to them. The user can read and write to the file. The group can read it. Others can also read it. So let’s remove a permission to lock this file down. Go back to your root terminal that is open or ‘sudo -s’ to root again and do the following:

[root@lostlap ~]$ chmod o-r example.txt

Now go back to your user terminal and take a look at the file again:

[devnet@lostlap ~]$ ls -l example.txt
-rw-r----- 1 testuser1 testgroup 8 2010-05-28 10:21 example.txt

Once that has been accomplished, try and open the file with your favorite text editor as your currently logged in user (devnet for me):

[devnet@lostlap ~]$ nano example.txt

Your user now should get a permission denied error by nano (or whatever text editor you used to open it). This is how locking down files and directories works. It’s very granular as you can give read, write, and execute permissions to individual users, groups of users, and the general public. I’m sure most of you have seen permissions commands with 777 or 644 and you can use this as well (example, chmod 666 filename) but please remember you can always use the chmod ugo+rwx or ugo-rwx as a way to change the permissions as well. I liked using letters as opposed to the numbers because it made more sense to me…perhaps you’ll feel the same.

Hopefully you now have a general understanding how groups, users and permissions work and can appreciate how the complexity of it is also elegant at the same time. If you have questions, please fire away in the comments section. Corrections? Please let me know! Thanks for reading!

ICH6 Intel Sound on Unity or Mandriva PulseAudio Fix

I had been fighting for a very long time with pulseaudio on Unity Linux 2010…it just didn’t seem to work for me.  There were problems with having to mute and unmute the external amplifier channel in alsamixer in order to get sound to work.  On some boots there was no sound and on others, sound was fine.  When I finally installed TinyMe 2010 RC last week, I disabled pulseaudio all together to get the sound working with ALSA only.

Then the worst thing that could possibly happen on my Gateway M250 happened…ALSA stopped working and there was no sound.  I started pulseaudio back up to no avail…no matter what I did, nothing worked to get sound up and running.

It was about the time I wanted to carve the sound pieces out of my laptop and throw them across the room that I decided to give everything I tried in the past one more try.

I fixed it…and I was pretty amazed that the solution was as easy as it was having spent weeks upon weeks fighting the pulseaudio issue.  I can only surmise that I made a typo in the module that I needed to blacklist.  After this arduous journey, it came down to blacklisting the modem sound card to make things work.

To do this on Mandriva and Unity Linux you’ll need to blacklist the following module:  snd_intel8x0m.  Notice the ‘m’ on the end of the standard module snd_intel8x0 for the ICH6 sound card.

You can do this by editing the following file as root in your favorite text editor:  /etc/modprobe.d/blacklist-compat

Add the following line anywhere in this file:

blacklist snd_intel8x0m

After that, you can reboot to make sure the module is blacklisted.  I know there are more elegant ways to load and unload kernel modules but this is the easiest way to get the job done for new users.  Subsequent reboots resulted in still having sounds.  Thankfully, I didn’t have to rip my laptop apart in a quest to throw the sound portions.  I sure hope this helps others out!

TinyMe Linux For The Win

I was running Unity Linux 2010.2 with KDE 4.5 for around the last month.  I really like what has been done there but it seemed a bit heavy for my Gateway M250…the CPU fan was always on which told me it was always in high use.

I checked out Gnome 2.30 on Unity and found it to be delightful on my resources; however, Gnome doesn’t make me feel warm and tingly when I use it.  I find myself frustrated with its lack of configuration options…specifically, right click menu.  So I rolled my own using the base install of Unity.  That worked quite nicely but lacked much of the polish I became accustomed to when using KDE.  What I wanted and needed was a happy medium.   I found that happy place with TinyMe Linux.

TinyMe is based on Unity Linux 2010 and was previously based on PCLinuxOS.  It uses LXPanel, PCManFM and the Openbox Window Manager to handle the heavy desktop lifting.  The ISO I used was a release candidate and lacked much of the polish of the TinyMe stable release of the past.  Even though it’s a release candidate, I still found it quite stable and usable…especially since I know my way around the openbox window manager.

You can snag the TinyMe release candidate here:  http://distro.ibiblio.org/pub/linux/distributions/tinyme/

After a few adjustments of adding my favorite programs I was in business.

TinyMe RC 2010

Even without some of the programs that made TinyMe famous (like the TinyCC) this distro is both stable and robust which is a testament to the underlying Unity Linux core.  If this release candidate is any indication, look for GREAT things to come from TinyMe 2010’s full release…something I will be looking forward to!

A Canonical Controversy

Remember these past few months where Ubuntu/Canonical’s contribution to Gnome (or lack thereof) was called into question and the topic was on the tip of every Linux news website tongue (see closing thoughts for info links)?  Let’s throw some gasoline on that fire for your Friday!!  It’s time for a Barbecue!

Today, Mark Shuttleworth’s blog was added into Planet Gnome after he made a request for it to be added.  Why is this a controversy?  Mainly because some people want blogs that are featured on Planet Gnome to be from authors that are active in the Gnome community and to actually blog about Gnome as a topic.  If Canonical’s contributions to Gnome are being called into question (as evident from the links in closing thoughts below) then what results is a controversial decision for Mark’s blog to be added in.

If you read the comments on the buglist issue, you will see that there are quite a few people in opposition to this move.  According to the Planet Gnome FAQ, there are criteria for being added.  Does Mark’s blog fit the criteria?  A close examination will result in a resounding NO.

Examining the Evidence

The evidence?  Mark has only one, single post on the topic of Gnome on his entire blog.  Is it recent?  If 2008 is recent, then yes, it’s recent.  If that’s not recent enough for you then no, it fails horribly on being recent.

Up next, let’s pull from the Planet Gnome FAQ, “It generally helps to write a few words about you and your contributions to GNOME, or why you think your blog should appear on Planet GNOME”.  Looking at the bug that was filed we find no explanation as to why it should be added other than “I contribute via Canonical”.  This phrase is going to be flogged by those people that were/are irked with Canonicals level of contributions upstream.

Lastly, since Mark is the face of his company, does this mean Gnome supports his company more than say…CEO of Red Hat or Novell since those CEO’s are not added on Planet Gnome?  Does this constitute a conflict of interest?  Does it signal favoritism?  If one person believes it to be this way, everyone loses…because there will be a debate about it and it WILL divide people and not unite them.

To be honest, I can’t believe Mark even asked to be on Planet Gnome as the CEO of Canonical.  He should know right out of the gate that it would look bad if he was added in…if it were me, I’d remove myself immediately.

Closing Thoughts

I said that this would be gasoline on a fire because of the firestorm debate surrounding how much Canonical, Mark Shuttleworth’s company, gives back to upstream projects like Gnome.  For more on that debate [1] [2] [3].

This is just the icing on top of the cake in my opinion.  Whoever decides what goes on Gnome and what doesn’t should really evaluate their processes and stop looking at a persons stature or bling factor and instead on the merit for them to be there.  In this instance, Marks blog provides little to merit its presence on Planet Gnome.

Please note, I’m not saying Mark hasn’t done anything at all for Gnome…just saying he doesn’t blog about it (and the evidence supports me on this claim)…and before a blog is added to Planet Gnome it should have more than one post in the past 7 years (yes, he started blogging in 2003) to be considered as a good candidate to be there.

What do you think?  Should Mark be on Planet Gnome?  Whether you agree or disagree, please state your reasons in a comment below!

Midori, Flash, and Unity Linux 2010

I just took a look at how Unity Linux 2010.1 shapes up and found that the flashplayer plugin doesn’t work with the default browser which is Midori.  Here’s a quick fix for getting flash to work with Midori on Unity 2010.  First, install the flash-player-plugin (as root in terminal or use the gui):

smart install flash-player-plugin

Next, we need to create a directory under your profile to house the flashplayer plugin and then copy it there.  I’m sure we might be able to get by with a symbolic link but I didn’t try that out…

mkdir -p ~/.mozilla/plugins && cp /usr/lib/mozilla/plugins/libflashplayer.so ~/.mozilla/plugins/

That’s it, it should work now.  I’ve done this on 32bit Unity Linux 2010.1 on a Gateway M250.  Hopefully this helps out someone out there 🙂

Finding Files with locate

Many Linux users use the ‘find’ utility when searching for files using the command line on their system. They’ll do a simple:

find / -name 'pattern'

Really though, the power of find isn’t just in finding names of files but rather specific details about those files. For example, if you wanted to find files which are writable by both their owner and their group:

find / -perm -444 -perm /222 ! -perm /111

or perhaps find any file that’s been altered in your Download directory in the past 24 hours:

find /home/user/Downloads/ -mtime 0

As you can see, the find command is very versatile and can be used to find an array of different attributes of files.  There are times though where I’m just looking for something and I don’t want to have to wait for the command to scan the entire directory tree in order to track it down.  That’s where locate comes in with quick and simple results.

Using the Locate Command

Using the locate command can only be accomplished if you install the mlocate package.  Most major distributions have this available.  If not, head over to the mlocate homepage and install manually.  Once that is accomplished, you’ll need to manually run a command to index your filesystem with it…otherwise, you’ll have to wait for the command to run automatically as it registers with cron to do so on a system level.  Open an terminal and change to your root user, then execute the following:

updatedb &

This updates the mlocate database that indexes your files and forks it to the background (the ‘&’ forks it to the background).  You can now logout of the terminal as root and the process will quietly work in the background.

After the command completes, using mlocate is as easy as using the locate command:

locate firefox | less

The command above will look for all files with firefox in the name and pipe the command through less so you can use the spacebar or enter key to scroll the file buffer.  Of course, the reason we pipe it through less is because any file that resides in the ‘firefox’ directory will be reported in the output.  While this tool isn’t as granular as the find command, it is a quick way to track down paths, directories, and files you know should exist.  Since the data is indexed using the updatedb command (by cron) the results are very quick and the command does not have to scan through the filesystem to return the results.

There are plenty more advanced options via flags (such as following symbolic links, making search term case sensitive, and even using regexp).  See the man page for details on how each of these options work.  Play around with locate and see what you can do!  It’s a powerful and quick search command!

Creative Commons License
Except where otherwise noted, the content on this site is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.