Welcome to back to Mike’s 4 Days of Extreme Geekery (yes, Geekery is a word I just made up)! On Day 1 we talked about traditional Unix file permissions. On Day 2 we talked about setfacl and getfacl. Today, I want to go over chattr and lsattr!

What these two commands do is pretty self explanitory. lsattr shows you the attributes currently on a file or directory, and chattr changes those attributes. You use either + or – to add or subtract attributes.

 mike@PreciseApex:~/mike/test$ lsattr mike
 -------------e- mike
 mike@PreciseApex:~/mike/test$ sudo chattr +i mike
 mike@PreciseApex:~/mike/test$ lsattr mike
 ----i--------e- mike
 mike@PreciseApex:~/mike/test$

The first time I found about the file attributes in Linux, I thought right away, “Hey, this is kinda like DOS!” I know what you’re thinking, and trust me if I could kick my own ass for saying that, I would. It turns out that the file attributes in DOS/Windows suck compared to the Linux version (like most things in DOS/Windows when compared to their Linux counterparts). Quick comparison will show you that DOS/Windows has 5 attributes. They are:

 R: Read Only
 A: Archive
 S: System
 H: Hidden
 I: Index

What each of these attributes does is, well, who cares. We’re not talking about DOS/Windows. The Linux version of file attributes is significantly more advanced. Available file attributes are:

 A: The date of last access is not updated (only useful for reducing disk access on laptops)
 S: The file is synchronous, the records in the file are made immediately on the disc.
 a: The file can be opened in addition to writing
 c: The file is automatically compressed before writing to disk, and unpacked before playback.
 D: The case is synchronous (see:S)
 d: The file will not be saved by the dump
 I: Can not be fixed by chattr only listed by lsattr
 i: The file / directory can not be amended, deleted, renamed or linked symbolically, not even by root.
 j: Mount file system with "data=ordered" or "data=writeback", and files are written to the log before the file.
 s: When the file is destroyed, all data blocks are being released to zero.
 T: Usable from version 2.5.46 kernel.
 u: If the file is deleted, its content is saved, it allows the user to seek its restoration.
 E: Experimental, can detect an error of compression can not be fixed by chattr, but can be listed by lsattr
 X: Experimental shows that the raw data to a compressed file can be accessed directly.
 Z: Experimental, provides information on the status of a compressed file.

As you can see, there are quite a few more file attributes that do significantly more. Some of these are more interesting than others. I’m only going to touch on a few of them that I find interesting. Of course, consult your man page for more information on the others.

The +A attribute basically locks that last accessed time to what it’s currently set at. Set this attribute, and you’re fill will be frozen in time. No more accesses will be recorded.

A really interesting one is the +c. This is an on the fly compression. If you add the +c attribute to an empty directory, everything you write to that directory will be compressed as if you stuck it in a file using gzip9 compression. One odd thing about it is that ls -l doesn’t show a darn thing. You can’t see the compression. I’ve heard that you can see it with a du, but when I was playing around with it, I didn’t see that.

I have to say that my favorite is the +i. I’m not sure what the i stands for, but I’m going with “Immortal”.

mike@PreciseApex:~/mike/test$ lsattr mike
----i--------e- mike
mike@PreciseApex:~/mike/test$ rm mike
rm: remove write-protected regular empty file `mike'? y
rm: cannot remove `mike': Operation not permitted
mike@PreciseApex:~/mike/test$ sudo rm mike
rm: cannot remove `mike': Operation not permitted
mike@PreciseApex:~/mike/test$ sudo rm -f mike
rm: cannot remove `mike': Operation not permitted

With the +i attribute set, this file can not be deleted. Not by the owner, not by root, not by anybody. You have to be root (or equivalent) to set this attribute, so no messing with your admins on servers you don’t own, but still fun.

The last two kind of have to be taken together. +s and +u. If a file with the s attribute is deleted, the blocks where it lived are zeroed out and written to the disk. Bye bye file. Good luck retrieving that one. In contrast, the +u makes sure that the files information is saved just in case you want to undelete it later. +s and +u are opposites. Oddly, you can set both flags on a single file. Not sure what that would do. If you know, throw it into the comments.

That’s an extremely high level view of the file attributes in Linux. I could probably spend weeks on these two commands going over what they do, but I have the feeling that I’d probably lose most of you in that amount of time. Tomorrow, I’m going to take a look at sticky bits! Bound to be fun!

Now, where were we? Oh yea, so the day before yesterday (I know I said I was going to do this daily, but the series finale of Eureka was on!) we covered what’s commonly thought of as the traditional Unix file permission. Permissions are applied using chmod, and can be seen as a -rwxrwxrwx at the front of the line after doing an ls -l.

OK, that’s all well, and good, but what do you do if you want to grant permissions to just a single person, or add different permissions to multiple groups? That’s where the crazy combo of setfacl and getfacl come in. I have a test file called “test”. If I do an ls -l on the file, I see these permissions:

-rw-r----- 1 mike users 0 Jul 15 22:35 test

So, this tells us that I’m the owner, and users is the group the file is assigned to (my group being the default). So, with these permissions, I can read and write to the file, anybody in the group users can read the file, and no one else can do anything with the file. Standard 640.

At this point, if I use one of our commands, the getfacl, I’ll see a little bit different information, but still basically the same:

# file: test
# owner: mike
# group: users
user::rw-
group::r--
other::---

But what if I want to give my wife permissions to that file, but no one else in the group users. One possibility is that I could create a separate group with just my wife and I in it and assign that group rights, but then the users group loses rights to the file. The simple solution is to just add my wife using this command:

setfacl -m u:amy:rx test

If I do an ls -l after this command, there’s only one slight change to tell us that we’ve done anything.

-rw-r-----+ 1 mike users 0 Jul 15 22:35 test

You can see now that there’s a + after the standard -rwxrwxrwx. This is a good sign. It means that our command was successful. If you were to do the getfacl now, you’d see this:

# file: test
# owner: mike
# group: users
user::rw-
user:amy:r-x
group::r--
mask::r-x
other::---

You can see now that the user “amy” has been added to the permissions of the file. If you were to do an ls -l command, you’d see that the group permissions would be replaced with the value in the “mask” field. This value reflects the last permissions applied to the file. A similar command can be used to add groups:

setfacl -m g:plex:rwx test

This gave full permissions to any users in the “plex” group. Now my getfacl looks like this:

# file: test
# owner: mike
# group: users
user::rw-
user:amy:r-x
group::r--
group:plex:rwx
mask::rwx
other::---

Through all of this, if I were to do an ls -l, the mask on that line would now show the permissions of the “plex” group, not the user “amy”.

-rw-rwx---+ 1 mike users 0 Jul 17 21:23 test

And if in the end, you decide that you would rather return to the standard -rwxrwxrwx Unix type permissions, it’s as easy as this:

setfacl -b file

After that command, the + is gone, and the getfacl returns to it’s defaults.

 -rw-r-----  1 mike users  0 Jul 17 21:23 test

# file: test
# owner: mike
# group: users
user::rw-
group::r--
other::---

Really, this is just scratching the surface. There is so much more that you can do with this, but again, I’ve gone on too long. Tomorrow (probably), I’m going to cover lsattr and chattr, and the day after I want to take a look at sticky bits!

First, a little side story. I like messing around with my Linux computer. I have fun just seeing what the operating system can do. I like to talk about what I find, probably because learning new things excites me. I get giddy when I find out something new about something that’s familiar. Unfortunately, in my house, no one cares but me. I sometimes try telling my wife about it, but to say she doesn’t care is an understatement. She doesn’t even pretend to pay attention when I’m talking any more.

I was playing around with Linux file permissions the other day. I’ve been using Linux on my personal desktop for over a decade, and I use it at work as a developer. I’ve never spent a lot of time where I was the one who administered a multi-user environment, so file permissions were always the basics for me. In my playing the other day, I found a whole bunch of new things that I never even knew existed, and since my wife would rather watch paint dry than hear me talk about file permissions in Linux, I’m turning to you.

I’m sure most people reading this post are familiar (at least superficially) with Linux file permissions. Simply doing an “ls -l” will show you the long listing format of the current directory. The very front of the line will show you the permissions of each file in the list. An example:

-rwx--x--x
drw-------

The top entry is a file, the second is a directory. Whether that file is a directory, link, or regular file is represented by the first character. – means that it’s a file, d that it’s a directory. Extremely simple. The next nine characters are broken down into three characters each representing the file’s permissions.

The first three characters are the owner’s rights, the second group of three is the Group’s rights, and the last group of three is the rights of everybody else.

What the example above shows us is that the owner of the file can read, write, and execute the file, the Group and the average user on the system only show execute rights. For the directory, the owner can read and write, but no one else can do anything at all.

These rights can be changed using the chmod command at the Linux command line. There’s a GUI to do this too, but I’m not going to deal with it right now because I really don’t feel like it. chmod uses a numeric combination to determine what rights to set. An example:

chmod 755 filename

This command give the file these rights:

-rwxr-xr-x

Basically, it gives the owner full rights to read, write, and execute. Everybody else can read and execute, but no writing.

Maybe I should be embarrassed by this, but for years I didn’t understand what the 7s or 5s or whatever represented. It seemed like arbitrarily assigned values. I was wrong about that, and the way that those values are arrived at is really ingenious in it’s simplicity. Let’s count a little bit in Binary:

1 = 001 = --x
2 = 010 = -w-
3 = 011 = -wx
4 = 100 = r--
5 = 101 = r-x
6 = 110 = rw-
7 = 111 = rwx

See what I mean? Brilliant in its simplicity.

There’s so much more to go into, but I’ve already gotten fairly long winded about this tonight. There will be at least two more parts to this little adventure I’m on. Tomorrow I want to cover getfacl and setfacl, and the day after lsattr and chattr.

If there are any more subjects on file permissions that you’d like to see covered, please let me know in comments and we can add more days.