Need to change CHMOD on directories - Security issues!?! - Directories now browsable!

[NeilFawcett]

All my old CGI directories used to be 711 (drwx--x--x). This allowed scripts to be run, but the directory to NOT be browsed.

To my alarm I've just discovered all my CGI directories are FULLY browsable to all the data files etc can happily be accessed from a browser!!!:eek: :eek: :eek:

What permission should a directory be to allow a CGI script access to the directory etc, but NOT a browser????

ps: This is not regarding the "cgi-bin".

[NeilFawcett]

I'm concerned about what I'm seeing here!

Permission 500 (r-x------) allows full browser access still, and the script can still be accessed. FTP access is still OK. Any attempt to reduce the owner permission then impacts on BROWSER access and FTP access!?!

Why is browser access affected by OWNER permissions (only)???

How can I NOT allow browser access, while still retaining FTP access!?

[tbonekkt]

A couple suggestions:
Try a CHMOD of 400 or 444. Put the directory you don't want web accessible above htdocs and modify scripts accordingly.

[NeilFawcett]

This is scary stuff!

With 444, this:-
a) Means the cgi script in that directory cannot be run!
b) WORSE STILL I CAN NO LONGER EVEN SEE THE DIRECTORY VIA FTP!!! (I've lost some directories now :( )

FFS! What the hell is going on!!!!!

Can't believe the advice from "staff" means a directory disappears for me :)

[NeilFawcett]

Odd! I have two directorys below HTDOCS, both with permission 711 and neither has a .htaccess files in it.

One is browsable, and the other reports:-
Directory has no index file.
Browsing this site or directory without an index file is prohibited.

Why do they behave differently?


The one that allows browsing is called "cgi". I think there's something funny going on regarding this specific name!

I created another directory in HTDOCS, gave it 711, and this also was not browsable. So only the "cgi" directory is browsable! Surely this proves something odd if going on with this specific directory?


EDIT: I've now removed the "Options +Indexes" line in my .htaccess file! This has obviously helped with now NO directory being browsable! All I need now:-
(a) The directories back which I've chmod'd so I can't even see them (eg: to 400).
(b) A recommendation of the actual permission a directory should be with a CGI script in! eg: 700?

I've raised a ticket with these questions in!

[djwtwo]

I just tried this - I set permissions to 400 in my FTP client on a test directory, and it vanished. Still 'visible' to scripts, though. I used the scheduled jobs feature to schedule an hourly job on the next minute that did this:

/bin/chmod 755 /home/users/web/bNNNN/pow.username/thedir

and let it run (then deleted it.) That returned the directory the the default permissions, which should be fine for CGIs. That wasn't enough to make it visible to FTP, curiously enough. I had to also "touch" the directory to do that. I did that, also by scheduling an job on the next minute that did this:

touch /home/users/web/bNNNN/pow.username/thedir'

let it run, and delete it. Bingo -- directory appears in the FTP client the next time I get a listing.

This is a little odd ftp behavior, though (in fact, I see a different owner on the files from the FTP server than I do from the web server.)

I've used the scheduled jobs interface like this, as a "poor man's shell", several times. Works pretty well for brief commands. Just to be clear, I create a new job, pick "command to run", enter my command line, and then set the job to run hourly on the Nth minute, where N is one minute past the current time. I then just wait until the job runs. Just be sure to delete the job when you're done with it.

[NeilFawcett]

I found the FileManager program could always see directories, and could therefore correct bad FTP CHMOD settings. I used it to "recover" my directories.

So the recommended setting for a directory in which a CGI script is being run is 755? Why not 700 for example? The latter two permissions seem to count for nothing now?

[Zombieman]

It's worth pointing out "directory browsing" and "permissions" are different things, but yes can partially do similar things.

The "permissions" of 755 on a directory actually means the "owner" of the directory (first digit) can read files it contains, write files it contains, and list the contents, whereas people in the same "group" as the owner (second digit) and "everyone else" (third digit) can only read files and list the contents, they can't write.

Put simply each digit is the sum of the permissions you want... "4" for read, "2" for write and "1" for listing the contents of directories, or for files this means you can "execute" the file as a program.

Anything that checks the directory contains a file before trying to use it will fail if the directory has a "4" permission, because it can't check, thus why "755" is fairly typical for web server directories ("644" for files) as it lets YOU update whilst "the world" via browsing is prevented from running amok. However in situations where the web server software effectively is the "owner" user, then the second two digits won't make any difference.

For any directories without an "index" page the web server itself will decide whether or not to display the contents of a directory, and you can control this behaviour either manually using a file ".htaccess" or by using the OPS control panel (Services > Site Tools > .htaccess > Open Directory Browsing)

As far as I'm aware the web server "directory browsing" feature defaults to being switched off on the new platform whereas it is/was switched on on the old one.

As a final comment, if you're paranoid you can always create an empty file named index.htm in any directories that don't have an index which you don't want to be browseable - I know of some CMS applications that ship with empty index.htm files in almost every directory for that very reason...

Hope this helps more than confuse.

[NeilFawcett]

Are we not in the situation (now) where the second two values are meaningless? ie: As far as permissions for the owner, or someone browsing via web (or running a script etc), 777 is no different to 700?

ie: Where a directory is by default given 755, it may as well be 700?

[Zombieman]

At present I have scripts on the server perfectly able to write to 755 directories and 644 files which suggests it would be no different if the directories were 700 instead, at present anyway. However if the PowWeb server configuration was altered to run the web server as "non-owner" to enhance security (many web servers run scripts virtually as "guest" accounts) any 700 directories would most likely not work. Hence the default.

[NeilFawcett]

OK... So where I used to have directories under 711 with powweb "classic", I'll retain them as that! Thanks!

Of course (I believe) 711 used to prevent browsers listing a directory, but this is no longer the case...