In my last article, I introduced the idea of permissions in the Linux world. Some users can read or write a file, while others can only read the same. A user may also belong to a group and share the permissions of that group which might also involve the ability to execute, or run a file as a program. Today, I'm going to continue on the subject of permissions but get into more detail, including some intense variations of basic permissions.

The setuid bit

Aside from those three permission bits (read, write, and execute), we have one other very important one.  That is the “s” bit, sometimes referred to as the setuid or setgid bit depending on its position. 

The reasoning behind this particular bit is as follows.  Sometimes you want a program to act as though you were logged in as a different user.  For example, you may want a certain program to run as the root user.  This would be a program that you want a non-administrative user to run, but (for whatever reason) this program needs to read or write files that are exclusively root’s.  The sendmail program is a perfect example of that.  The program needs to access privileged functions in order to do its work, but we want regular (non-root) users to be able to send mail as well.

The setuid bit is a variation on the execute bit.   In order to make the hypothetical program, ftl_travel, executable by anyone, but with root’s privileges, I would change its permissions like this.

chmod u+s ftl_travel

The next step, as you might guess, is to combine full permissions and the setuid bit.  Start by thinking of the setuid or setgid bits as another triplet of permissions.  Just as you could reference r, w, and x as 4, 2, and 1, so can you reference setuid as 4, setgid as 2, and other (which we don’t worry about). 

So, using a nice, complicated example, let’s make that command so that it has read, write, and execute permissions for the owner, read and execute for the group, and no permissions for anyone else.  To those with execute permissions, though, we want to have it setuid.  I could also represent that command either symbolically or in a numerical way.

chmod u=rwxs,g=rx,o= ftl_travel
chmod 4750 ftl_travel

The 4 in the front position represents the setuid bit.  If we wanted to make the program setgid instead, we would change that to a 2.  And, yes, if you wanted the executable to maintain both the owner’s permissions and that of the group, you would simply add 4 and 2 to get 6.  The resulting set of permissions would be as follows.

chmod 6750 ftl_travel

Changing the setuid bit (or setgid) is not strictly a case of providing administrative access to non-root users.  This can be anything.  I might have a database package that operates under only one user-id, or I may want all users to access a program as though they were part of a specific group.   You will have to decide.

Important note : You cannot use the setuid or setgid bit for shell scripts (although there are perl hooks to do this).   This won’t work for security reasons.  If you need to have a script execute with a set of permissions other than its own, you will have to write a little C program that wraps around your script and allow it, rather than the script, to have setuid (or setgid) permissions.

File Attributes

Unfortunately, the first time most people run across file attributes is usually after their system has been cracked.  Yes, I tend to use the term cracker, rather than hacker; hackers are not, by default, malicious. What happens is that you try to update a package that you know has been modified and the system will not let you.  So, you try to delete the file and that still doesn’t work.  You check your user id and you are logged in as root and still, you cannot get rid of the file or update it with a clean version.  What is going on?   Isn’t root supposed to be all powerful?

You have probably just run across a file with the “immutable” attribute set, which means that under no circumstances can you move, rename, delete, or write to the file. 

For the most part, most users never wander into this territory and this tends to be a largely ignored aspect of the Linux file system .   The first command to look at here is “lsattr “ which (you guessed it) lists the attributes of any given file.   Normally, your stock system will have none of these permission-like bits set, so using the lsattr command will show something like this.

# lsattr secret_document 
------------- secret_document

The dashes all of which represent a position marker for a number of attributes that can be set (or changed) using the chattr command.  

chattr +attribute file_name

Let's see this in action. In the next example, I am logged in as root, so I should have permission to do anything, including delete a file.

root [~]# chattr +i secret_document

root [~]# lsattr secret_document 
----i-------- secret_document

root [~]# rm secret_document 
rm: remove write-protected regular file `secret_document'? y
rm: cannot remove `secret_document': Operation not permitted

As you can see, once the immutable bit is set, even root is powerless. Or so it seems. You can also use a minus sign (–) to remove attributes, or the equal sign (=) to set a number of attributes at the same time.  Some of the attributes must be set by the superuser alone.  These are a, and i.  The “i” attribute is the one that makes a file immutable and the most interesting one to me. Now, why would you want to bother yourself with any of this?  Think back to how I introduced this section and my immutable file.  You can do the same thing to protect yourself.  Take those system files that you absolutely do not want anybody modifying in a remote session and add this attribute.

The other root-only attribute is “a”.  Setting this bit means that files are append only.  In other words, you cannot simply overwrite the files.  This might be a good thought for log files that you don’t want someone suddenly clearing out.  Here’s an example of this append attribute in action. 

[marcel@localhost ~] $ chattr +a test.txt
chattr: Operation not permitted while setting flags on test.txt

[marcel@localhost ~] $ su - root
Password:
[root@localhost /root]# touch test.txt
[root@localhost /root]# chattr +a test.txt

[root@localhost /root]# /usr/games/fortune -l > test.txt
bash: test.txt: Operation not permitted
[root@localhost /root]# /usr/games/fortune -l >> test.txt

When I first tried to set the attribute, I was working as a regular user and you can see where that got me.   I tried again, but this time switched to the root user first.  I used the touch command to create a blank file, then set the append attribute.  The first time through, I simply redirected the output of the fortune program (using the greater-than sign) but was refused even though I was running as root.   Only when I started appending my output to the file was I allowed to do so.

Other permissions you can set in this way are include some of the following:

Attribute A : Don’t update the access time information on files.  For frequently accessed files that don’t change a great deal, this can provide a performance improvements.  The catch, of course, is that you can’t track access time on the files.  This can also be set for an entire file system.

Attribute c : When this file is not being accessed, the system automatically compresses it.  Anytime the file is accessed, it is uncompressed.  This may or may not be valid on your system since it was not yet fully implemented as of this writing.

Attribute d : Files marked in this way will not be backed up by the dump command.  The dump command can be used for backing up and restoring your system.

Attribute s : Think of this as the paranoia bit.  If you set this on a file, it will be completely zeroed out when you delete it.  In other words, someone scanning your disk at the bit level will see no trace that it had ever existed.

Attribute S : All files tagged with this bit are automatically synchronized to the disk whenever any changes are made.

There are other attributes which can be set and unset as seen here. 

+-=[acdeijstuACDST] 

To find out what each of them does, you can use the man command to view the options to the chattr command.

man chattr

And with that suggestion for further exploration, I leave you for another day. Join me next Monday for the next part of this series on command line Linux. If you wish to comment, please do so here on Google Plus or here on Facebook. Remember that you can also follow the action on CookingWithLinux.com where it's all Linux, all the time. Except for the occasional wine review. Also, make sure you sign up for the mailing list over here so that you're always on top of what you want to be on top of. So to speak. Until next time . . .

A votre santé! Bon appétit!