More Directory Permissions

[Anonymous Monk]

This is like an addon to maleteen's question.
What permission code would you give so that owner (me) has full permission, group and other have access to the files within, BUT group and other cannot go STRAIGHT to the directory? (Where if they do so, they get "Forbidden")
I know how to figure out permission codes (4 for read, 2 for write, 1 for execute), but don't know what "group" and "other" is. I am "owner", right?
Thanx.

[kudra]

Nothing to do with perl, but I'll bite.

I believe what you want to do is prevent someone from getting a list of the files in the directory, while still allowing the person to view files within the directory, if s/he knows the filenames.

You can do this by making the directory unreadable:

chmod go-r <dir>

while making files within readable. A 'ls' will then give a 'permission denied' for group and other.

But, like athomason, I get the impression that perhaps you are talking about httpd permissions, because of the use of the term forbidden. If what you want is to not give a directory listing (http://blah.com/ will give an error if the default filename isn't found) you can use the same solution.

Or, assuming you are using apache, you can modify srm.conf (or httpd.conf). You need to create an entry for the directory in question. It might look something like this:

<Directory "/home/foo/public_html">
    AllowOverride All
    Order allow,deny
    Allow from all
    # Options Indexes
</Directory>

It's the "Indexes" option which toggles the directory listing permissions. Include it and permission is granted, remove it and it is removed.

[questor]

There are only three bits, r, w, and x, for each of the groups of users (u, g, o) in the Unix permission scheme, so the meanings of these bits get a bit convoluted at times. (Actually, there's three more, setuid, setgid, and sticky, but they're even worse.) For directories, r is the ability to read the directory, to list its contents. If you don't have this, ls directoryname fails. w for write means adding, deleting, or renaming (moving) files; if you've got w permission, you can remove a file even if you're not the owner of the file (unless the sticky bit is on -- like I said, worse).

The x bit is probably the most interesting to the person who posed this question: this bit being on allows (and is necessary for) two things: "cd"'ing to the directory, and moving though the directory to access files and subdirectories. If you have x but not r, you can't read the directory but if you know a file/subdirectory is there, you can operate on that file/subdirectory according to your permissions on that item. Conversely, if you have r but not x, you can see the item but can't do anything to it: ls will show it exists, but ls -l will fail on trying to give you any of the attributes of it, it can't go through the directory to get at the file and find its attributes.

x without r, or r without x, is generally not too useful; so directory permissions tend to be (numerically) 7s or 5s where access is desired (depending on whether write is on or not). Having just x on isn't much of a security hole, since it doesn't provide any information, and one still needs still needs permissions granted on the subitems to do anything with them, so frequently one will just leave x on (1 numerically). So directory permissions will tend to be all-odd (751, 711, etc.), while non-executable files are all even (644, 640, etc.) (since you don't want to have your letter to your mother treated as an executable shell script).

[chromatic]

If you're in a web environment, there are server directives that prevent directories from listing when someone asks for a bare directory.

For Apache, you can specify Files to be served by default.

(The word "Forbidden" makes me think you mean a web environment. This is really more of a server issue than a Perl issue, though.)

[mikfire]

Remove the read permissions. If somebody knows the fully qualified path name(fqpn), they can read that file and, by entension, execute the file if the file's bits are correctly set. But they cannot get a listing of the directory's contents. Be warned, though, that they can look at the permissions of any file to which they have the fqpn, ie, they can do an ls -l against the file.

Mik
Mik Firestone ( recovering sysadmin )

[athomason]

Seems a bit off topic for the site, but oh well. I'm not quite sure what you mean by "go straight to the directory"... I'm assuming you don't want a directory listing to be allowed. Since this is in reference to maleteen2000's question, I'm guessing you're refering to file system permissions rather than web permissions (though "Forbidden" sounds more like a httpd error than an OS error). If that's so, I don't think you can do that (i.e. prevent directory listings while allowing file access), at least not according to a quick test I did on Solaris. But I don't know why you would want to, either... you'll hear quite often that security through obscurity isn't security at all. Can you be more specific about what you want to do?

As for what the three concerned parties are (u, g, o), do an 'ls -l' in a directory to see all the file permissions and owner and group settings. Each file has an owner (you, if you created the file), and a group. When trying to access a file, the OS first checks to see whether you're the owner of the file; if so, owner (u) permissions apply. If not, it checks to see whether you're a member of the group to which the file belongs; if so, group (g) permissions apply. If neither of these is true, other users' (o) permissions apply. Unless you've explicitly set up groups so that the group is trusted somehow more than others, you'll probably want to set the permissions for group and others the same (almost always without write, read and execute depend on what you want).

[Anonymous Monk]

Thank you all. I have decided to use 0755. It seems you all wasted a lot of time answering the question.
I thought it would be simple, and in a way it was. Yes, I meant in a web environment.
All I had to do was use 0755, meaning allowing read and execute to all users, and write for owner.
Thanx for all of your help :-)

[Jonathan]

Allowing access to files but not the directory they are in is incompatible. Permissions along the line of 755 would allow the file access you want. As you suspect you are the owner. Groups are collections of user accounts that can be given their own permissions. For Example, a group called "finance" could include all users of a finance area who would have their own files they could use where another group "workers" would not allowed. Others is the rest of the world. When people refer to permissions like 755 They represent the permissions in owner,group,other order. Is this a perl free zone? :-)