Linux

Linux 101: File permissions from the GUI point of view

For new users to Linux, there might be times when you need to change the permissions of a file. Jack Wallen shows you how this is done without having to touch the command line. With just your file browser, you can work all the file permission magic a new user needs.

Last week I had one of those real eye-opening moments where it finally dawned on me just why Windows can be so insecure. File permissions. From the Windows OS perspective, everything is executable. It doesn't mean everything does something, but pretty much everything can be seen as an executable file. That is dangerous. Linux, on the other hand, doesn't apply the executable bit by default. So, conversely, unless specifically given executable permission -- Linux sees everything as non-executable. With that in mind, I thought I would demonstrate how to work with file permissions in Linux -- but from the perspective of the GUI (since most file permission how-tos focus on command line -- and my goal is to help people migrate to the Linux desktop).

But first, a few general words on Linux file permissions.

There are really three bits the end user needs to know about, and every file on a Linux system works with them. Those bits are:

  • R -- read
  • W -- write
  • X -- execute

There are also three different users you need to be aware of:

  • Owner -- the user that created the file
  • Group -- the group of users that have ownership of the file
  • Others -- all other users on the system

With that simple knowledge under your belt, let's examine what happens when you create a file. Let's say we're going to use LibreOffice to create a text document in the Documents directory of user 'jlwallen'. If we open up LibreOffice, start writing a document, and save the document in /home/jack/Documents, the file permissions are automatically set such that:

  • Owner (jack) has read/write permissions
  • Group (anyone in the 'jlwallen' group) has read/write permissions
  • Others have read permission

Figure A

Figure A shows how this is displayed in the Nautilus file browser.

Clearly a text file created in LibreOffice does not need to have execute permissions. But what if you were creating a bash script (using, say, Gedit)? Even still, the permissions will be the same. If that script needs to have executable permissions, what can you do? It's quite simple actually.

Open up the Nautilus file manager, navigate to the Documents directory, right-click the file, select Properties, and click on the Permissions tab. To give that file executable permissions, you simply check the box for Execute. The one caveat to that is all users get executable permissions. If you want to get more granular than that, you would have to use the command line. Of course, if you're getting into bash scripting, you are most likely okay with the command line.

Figure B

But what if you were on a multi-user system and you wanted to make sure that you were the only user on the system (outside of root, of course) that could even view the newly created file? To do that all you would do is select None from the Access drop-down for both Group and Others. If the Execute check box is still checked, the only thing Group and Others could do is execute the file -- they cannot read it or edit it. If you want confirmation of that, you can open up a terminal window, change to the Documents directory, and issue the command ls -l. Figure B illustrates how the file permissions now look from the command line.

With this knowledge in hand, you could, effectively, create your new bash script using Gedit, give that script executable permission, and then launch the script -- all without ever touching the command line.

This will also come in very handy when you download an installer that isn't a .deb or .rpm file and need to run it. These files can often be in the form of .bin. In this case you must do the following:

  1. Open the file manager
  2. Navigate to where the file was downloaded
  3. Right-click on the file
  4. Select Properties
  5. Click on the Permissions tab
  6. Click on the check box for Execute
  7. Close the properties window
  8. Double-click on the installer
  9. Install the application

Some might say this is a bit of a hassle that these extra steps are necessary. But having the security of knowing that not just any file can be executed is worth those extra steps.

Now you have the ability to manage your file systems without having to touch the command line. No, you can't get as granular as you can with the chmod and chown commands, but for those that aren't ready for the terminal (or simply don't ever want to bother with it), the file manager gives you just enough power to make those files work for you.

About

Jack Wallen is an award-winning writer for TechRepublic and Linux.com. He’s an avid promoter of open source and the voice of The Android Expert. For more news about Jack Wallen, visit his website getjackd.net.

8 comments
PhilM
PhilM

What happens when you wish to have two groups but with differing riggts? e.g. a "Sales" group who have read access to a folder of client details and the "Sales admin team" who have read \write rights to that folder to maintain the details? Can you have more than one group assignment in Linux? Be nice in your replies please :-)

andrew5859
andrew5859

Hey Jack, Nice article and all, but not all Linux OS's automatically have file sharing when you've installed the OS. Most times you have to go into Synaptic Package Manager, download and install the proper files to do this.....you would also ahve to download and install the appropriate files for opening files as Admin. This issue then falls on the Devs (Developers) of that particular OS, (sometimes, you're talking to deaf ears, because most devs don't listen to their base and just do as they want, regardless of input....sounds familier..gov't :P ). So, unless the devs are willing to listen to those who are using the OS, it doesn't really do any good, thus people are turned of by a particular Linux OS (s). These things need to be made ready to go right out of the box or from the download of a or any given ISO.

james.vandamme
james.vandamme

..and who's in a group, how to start one, and what they are good for, anyhow.

pgit
pgit

Any user can be in any number of groups. So in your scenario set the limited access guys in one group, "sales," and set the admin guys in both the "sales" group and an "salesadmin" group. Then on the shared folder, set the salesadmin group read/write at the user and group level, with "others" being able to read only. Seeing as "sales" in an "other" group relative to "salesadmin," they will be able to read but not write. Access listing is also possible, as mentioned by other's posts above. (eg use ldap, kerberos or an acl) There are active directory-like apps as well, Mandriva has an enterprise AD replacement available that handles both Linux and windows clients.

maj37
maj37

The short answer is no, that is one of the problems with UNIX, and Linux, security it has very little granularity.

The_Real_BSAFH
The_Real_BSAFH

Windows? Windows file security is a joke within a joke. Troll elsewhere please.

hairy_Palms
hairy_Palms

This is perfectly possible, you would use Access Control Lists,

Editor's Picks