View Full Version : File Execute permissions

1st March 2005, 01:06 PM
I'm new to Linux and I have a very strong Windows background.

My question is: what is the purpose and/or effectiveness of EXECUTE permission in Linux. As I understand it, if a LAN user has read access to a file (no execute) then couldn't he just copy the contents of that file into his home folder make this file executable and run it :confused: ? This would really defeat the purpose of this permission setting.

The way it works in NTFS is if you can Read a file, then you can Execute it. This makes more sense to me atm.

Please explain,


1st March 2005, 01:43 PM
My question is: what is the purpose and/or effectiveness of EXECUTE permission in Linux. As I understand it, if a LAN user has read access to a file (no execute) then couldn't he just copy the contents of that file into his home folder make this file executable and run it :confused: ?
yes but he could not have option to run anything from his home either (his home filesystem mounted with noexec option - so he can't exec anything from here)... it is easy to trick (f.e. use /tmp dir if not secured). also exec permission can be set on directory:

reading directory means when you give specific path f.e. "/some/dir/file" than you can read this file from this directory. executing directory means listing its content...

The way it works in NTFS is if you can Read a file, then you can Execute it. This makes more sense to me atm.
you can make Linux filesystem more like NTFS by using extended attributes aka ACL (access control list).

1st March 2005, 02:05 PM
it is easy to trick (f.e. use /tmp dir if not secured)

So basically, is it not very safe to rely on restricting execution of files, unless you can deny execute permissions everywhere else on the system (so that you can't just copy file contents)? Is that effective at all in practice ?

Can you give me more info on ACL - does EXT3 support this ? How can I utilise this functionality ?

2nd March 2005, 10:03 PM
The execute permission keeps a user from executing (running) a file. You're right that
someone could copy the file (with read permission) and then make their executable.
Usually though, they wouldn't want to. The execute permission is often removed from
files which should not be executed anyway. Image files, music files, etc are not ment to be
run and usually have their execute permission removed to prevent someone from trying
to run them (sometimes by accident).

More often, the lack of an execute permission is used on a directory. For example, you probably
don't want people getting access to your home folder, so you remove execute (enter) permission
from that folder. (In those cases you usually remove read and write permission too.)

3rd March 2005, 03:46 AM
So the execute permission is more of a safety/precautionary feature.

"kosmosik" mentioned above that there's a way to imlement an ACL on the EXT fs. How can this be done ?

3rd March 2005, 04:15 AM
Actually, the execute bit is used by the OS to flag files that can be run, although you can control who runs them by turning off the group/other execute bits (permissions are actually octal numbers).

You implement ACLs with SELinux, I believe. I've stayed away from it at the moment because it's just too dang new and there seems to be some issues with it.

3rd March 2005, 04:25 AM
So you could compare the execute bit so Windows .EXE file extension... sort of, right ? That makes some sense.

Since we're kinda of the topic of bits, could you explain what an inode is? As far as I understand, inode is the physical file id (if you can call it that) on the file system. Also, hard links - if you have 1 file, 2 hard links to it and then delete 1 - the file will still exist, correct? So filenames are stored in the FS's file table, and point to inodes. Or am I completely off the mark here ?

5th March 2005, 04:13 AM
Let's see if I can take a stab at this.

I think of the file system as being broken down into three parts, or
at least for the purpose of this explination. These parts being
1. Directory entries.
2. Inodes
3. Physical files, raw data.

When you create a new file on the disk you make an inode. That inode
contains info on where the data is on the disk, I think it's size and
how many links (directory entries) there are to the file.
When you make a new link to the file, you create a new directory entry.
As I recall, you still have one Inode and only the one file, but you have
an index (a directroy listing) in two places. When you make the new link,
a counter is increased in the Inode.

Now, when you delete a link (a directroy listing) the counter in the
Inode is decreased again. When the number of indexes (directory listings)
reaches zero, there is no longer any need for the file. The Inode is
then deleted. The raw data itself is (usually) left on the disk, but since no
Inodes point to it, it doesn't show as taking up any space.

It's been a while since I took UNIX File Systems 101, so please feel
free to correct me.

5th March 2005, 01:22 PM
Thanks for that - that's was one of the most enlighting posts I've read in a while :P.

What about directory listings? From your explanation, I understand that inodes don't have permissions bound to them. That leaves the actual directory listings (since links can have different permissions). Can you explain about them as well please? How are they organised? Where are they stored? Where do extended permissions (incl. ACL) come in?

Also, where can I learn more technical info on Linux - I've looked at some books but they're all for simple-minded front-end users.

5th March 2005, 03:38 PM
Actually, as I understand it, the inodes do hold the file permissions. If you have a file
(let's call it ABC) and you make a link to that file called (DEF) both files have the
same permission. If you change the permission on the DEF link, the permissions
change for ABC as well.

Now, I'm not sure, but I'm fairly sure file permissions are stored in the inode.

There is a different kind of link, called a symbolic link. This links are
really more like Windows Short Cuts. They are seperate files which "point"
to the data. Symbolic links, being different files, do not effect the original file's
inode. When the original file is deleted, the symbolic link becomes useless.

Hope that helps a little.

5th March 2005, 05:24 PM
And to further add to the confusion, directories are actually files (and thus have an inode) as well. You can see this "in action" if you type in

less .

5th March 2005, 07:14 PM
Thanks for confusing me - mission completed! I thought there is a FileTable somewhere in the 'beginning' of the HD and then all files are linked to a directory in that table. But if directories are Inodes - where is how is the hierarchy stored. I understand that if this is the case then you can still build a file/directory structute by referencing a 'parent' Inode to find where the file/directory in question is located - but would this make recursing directories slow and painful to the HD?

Also, how are permissions and other file-specific properties stored? RedFedora mentioned before that these are attached to Inodes, not directory entries. Does enabling ACL then pretty much incur a full filesystem conversion to handle the per-Inode information overhead? An what happens as you add more ACL entries to a file (say, read+write permissions to 3 specific users and read permissions to 5 other specific users)?

5th March 2005, 07:21 PM
To add to my prev. post, I checked if directories are in fact Inodes using the 'stat' command and I must confirm that they are, even "/":

[root@linx ~]# stat /
File: `/'
Size: 4096 Blocks: 16 IO Block: 4096 directory
Device: 2102h/8450d Inode: 2 Links: 24
Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2005-03-06 04:02:29.044248337 +1100
Modify: 2005-03-01 15:47:50.456661232 +1100
Change: 2005-03-01 15:47:50.456661232 +1100

Output from the 'less /' command shows that directories have permissions attached to them. That must mean that they're Inodes...?

[root@linx ~]# less /
total 282
drwxr-xr-x 24 root root 4096 Mar 1 15:47 ./
drwxr-xr-x 24 root root 4096 Mar 1 15:47 ../

So, that leaves me very confused and hoping for some explanation(s) :).

6th March 2005, 04:46 AM
Okay, I'm out of my depth in terms of how the filesystem actually functions. I just showed off my one golly-gee whiz trick (knowing that a directory is just another file). :p

6th March 2005, 09:44 AM
Great! Well at least you admit that you're not the smartest guy here :P - that's makes me feel much better, 'cause I'm not feeling like I'm asking stupid questions any more.

Now we can both wait for an enlighting answer from someone who's smarter that us. Can 'RedFedora' help?