Questions about permissions of files and directories.

The index.php page is readable (ie accessible from a web browser) if the permissioning of the directory is set as follow:
drwxr-xr-x 3 author author 1024 Feb 1 02:43 .
drwxrwxrwx 40 upload upload 1024 Feb 26 12:57 ..
drwxrwxr-x 4 author author 1024 Jan 29 02:32 pics
-rw-rw-r-- 1 author author 13174 Feb 1 02:45 index.php

However, it won't display if it's as follow:
drwxr--r-- 3 author author 1024 Feb 1 02:43 .
drwxrwxrwx 40 upload upload 1024 Feb 26 12:57 ..
drwxrwxr-x 4 author author 1024 Jan 29 02:32 pics
-rw-rw-r-- 1 author author 13174 Feb 1 02:45 index.php

The only different is that the group's and other's permission has read only right rather than read + execute right on the directory. Can I ask how does the removal of the execute right on the directory prevent others from reading the content of it?

In addition, I also notice that if I "chown root:root <directory>", and then "chmod 755 <directory>", user "author" can still remove the files under the "pics" sub-directory but not the "index.php" file. Isn't it true that if the parent directory is owned by root and there are no write permission for group and others, no one other than the root can write (ie remove) the contents?
drwxr-xr-x 3 root root 1024 Feb 1 02:43 .
drwxrwxrwx 40 upload upload 1024 Feb 26 12:57 ..
drwxrwxr-x 4 author author 1024 Jan 29 02:32 pics
-rw-rw-r-- 1 author author 13174 Feb 1 02:45 index.php

Directories have to be executable to be opened.

The Author user and group own the pics directory, and have write permissions on it, so they can do what they want within it, as long as they can get into <directory>. Which they can because even though it's owned by root, its permissions are 755. However, index.php is within <directory> which the author user only has read and execute permissions on. Author cannot remove the pics directory because that involves a write to <directory> which they cannot do.

BTW that's a very confusing listing you gave.

Hello,

Apologies on the confusion. You meant the title or the body? I tried to make the body a bit easier to read but guess failed on that part. Thanks for taking the time to read over it.

So basically, in Linux and UNIX systems, I can make the following statements, assuming the following structure?
<Directory A>
->[File A]
-><Directory B>
->[File B]

Assumptions:
1) <Directory A> is owned by root with 755 permission.
2) Everything inside <Directory A> is owned by me with 755 permission.

Statements:
1) I can not remove, rename, or over write [File A] even if I am owner and have permission just because I don't own and have permission on <Directory A>? I also can not rename, or remove <Directory B>.
2) I can, however, do anything I want with [File B] because I am owner and have permission on both <Directory B> and [File B], despite the fact that [File B] is under <Directory A>.

What troubles me is the fact that the Linux/UNIX system is treating [File B] in a different way than [File A] and <Directory B>. I have ownership and permission on all these 3 items. However, I am only permitted to do what I want on [File B] because the immediate parent of [File B] is owned by me. So it appears what counts are having permissions on both the immediate parent of the item, and the item itself.

Yes, your assumptions are correct. Of course in the real world, you as a user wouldn't be able to create any files or directories under a directory owned by root with perms of 755, so the situation doesn't come up.
But it does come in handy for root to be able to control access sometimes.
And not just root. If you have a web server and apache can write to a file inside a users directory, you don't necessarily want apache to be able to delete the directory.

It seems confusing at first, but if you think about it, you can only have permissions to write or delete in a downward direction, not an upward direction. Otherwise you can do things you are not allowed to. Another example is the /home directory.
You have a users directory in /home/user
The user can delete or write anything below /home/user but nothing above that. Otherwise, they could affect the directory /home/user2

Neither user owns /home, root does.
regards

Alan

Well the troubling part is why the treatment for [File A] and [File B] is different. Both files are owned by the same owner with the same permission. Both are also under <Directory A>. It's just that [File A] is immediately under <Directory A>, and [File B] is two level down from <Directory A>. Why it's made to be like this? Windows doesn't behave this way and it makes more sense that way.

It's not troubling and who cares what windows does.
Permissions are always dictated by the top level, no matter what.
If you think that the people below a certain level should have more permissions than the ones on top then you're in the wrong game.

You can do what you want unless it's against the law. Do you get to decide the law ?

Answers on a postcard please ...

[edit] deal with it.

I'm with smoker on this one! UNIX file permissions are one of the reasons that UNIX and linux not to mention many other systems, have been so successful. It's because simplicity is key. The OP compares to Windows, but it must be noted that under Windows, NTFS file permissions are controlled using Access Control Lists (ACL's), and so inherently are different from linux. It is possible to use POSIX ACL's in linux if you really want.

Well, in this case it really doesn't appear to be very secured. Given the following structure, I thought to secure against modification of everything under <Directory A>, I can just change <Directory A> to be owned by root with no write permission for anyone else. Turns out [File A] and [Directory B] can't be deleted by user but [File B] can. So it doesn't really correlate with the idea that if the top level is locked, the child levels are also locked. It also doesn't really correlate with the idea that if the file is owned by the user and permitted, it can be modified by the user.

<Directory A> owned by root with 755
->[File A] owned by user with 755
-><Directory B> owned by user with 755
->[File B] owned by user with 755

As for Windows, is there anything UNIX/Linux based system can do and Windows can't? I have not heard of such a case.

The top level isn't "locked" if the permissions are 755. 750 would lock it.

On a unix system you can do pretty much anything you want, but on a windows system you do what it allows you to, unless you pay. If you want a windows / *nix flame war go elsewhere.

First of, I'm trying to understand 1) the workings of the file system, 2) what it is that the UNIX/Linux system can do and Windows can't in terms of security.

Second, given a permission of 755, doesn't this mean the group and others can only read or execute, but not write or delete?

As for the paying for it, I see no arguments here. At least they have the solutions available. Most of the products purchased aren't OS stuff anyway. If someone needs to buy a database, it needs to be paid anyway whether it is SQL Server, Oracle, or Sybase. Now you can even use SQL Server Express for free and it's more powerful than the free MySQL offering from Sun. Same thing with monitoring tools. But yes, you don't need to pay for Office as you have Open Office. However, you also don't have to pay for Sharepoint but Sun doesn't even have an equivalent available. Same for built in clustering support in MS but companies use Veritas for UNIX. So I don't buy the paying for MS vs non-paying for UNIX idea. And there really is no point argument over stuff like this. Like I said, I'm trying to find out if there are anything UNIX/Linux can do but Windows can't. Just want to have a civilized conversation and sharing of knowledge, not arguments.

The UNIX filesystem has no real concept of files being "under" anything they only have the concept of being 'listed in'.

FileA is listed in DirectoryA
FileB is listed in DirectoryB
DirectoryB is listed in DirectoryA

When you think about it in these terms it makes more sense, especially when you understand that FileA can be listed in DirectoryA AND DirectoryB.


The NTFS permissions model contains very different concepts (such as inheritance, groups being members of groups etc.) and really shouldn't be compared to the UNIX model.

Whether one considers inheritance of permissions and nested groups a good or bad thing will depend on ones viewpoint. Inheritance can lead to unintended results on occasion (especially so if you move something to a different location), and nested groups can muddy the waters when trying to see who can do what. Some people may consider that a significant risk to security.

Just got something by surprised. I have the following situation:
<Directory A> owned by root with rwxr-xr-x permissioning.

FTP onto server as "ftp_account" and tried to rename it, and <Directory A> was renamed to whatever I typed in. This doesn't make sense to me as renaming is a write operation to me, and without the write permission for groups and others, I am still able to do so with the "ftp_account". Strange.

renaming is a write operation on the directory the file/directory is listed in.
If you are able to rename or delete it then your ftp_account must have write access to the directory containing your DirectoryA

Thanks. This is a good thing to visualize. So basically in UNIX/Linux systems, the ownership and permission of the immediate parent and of the item itself is what matters, not the ownership and permission of say two levels up.

Each file in Windows have a number of attributes associated with it exactly like in UNIX/Linux. To really see whether a specific file maybe read or overwritten by anyone, one still have to check the permission of the individual items. But isn't this the same with UNIX/Linux based system also, given that UNIX/Linux only check for the file's immediate parent directory's permission?

What I guess you're saying is if an domain administrator moves a user from a normal user group to a privileged group, unless that administrator knows what exact right that new destination group has, potential locks may be opened or potential places may be allowed to be accessed inadvertently? However, I guess the same thing happens also in UNIX/Linux if the admin doing the move doesn't know what the destination group can do as well. This is just probably an easier risk to commit with Windows as a user can normally be associated with more than one group.

Sorry didn't see your very good explanation of the concept of "listed in" before I posted that question. Thanks for this very simplistic yet good explanation!