Question about symlink permissions

[Jake]

Hello,

Proud to be on a FutureQuest!

I am setting up a cgi script. The problem is it has a bunch of include and library files that it assumes to be in the cgi-bin.

I've read it is safer to put all non-executables out of the web document tree.

Rather than trying to get all the paths correct, can I just move them to /big/dom/xdom/user/folder/ and then symlink them?

<edit>Actually, I've already done this and it works. What I'm really asking is would that be the same as if I moved them out of the web doc tree and changed the hard coded paths in the script? Or am I still just as easy to get hacked into? And is it really anything to worry about?</edit>

TIA,
Jake (b-dylan.com)

PS - Why does it say visitor next to my name?

[sheila]

Hi Jake,

First things first... you ask:
PS - Why does it say visitor next to my name?
Well, because you need to visit this page:
http://www.FutureQuest.net/Community/SiteOwner/

and request site-owner status. ;)
Then you will get the really cool "Site Owner" label under your name.

Now, as to the symlinks...
Arthur sums it up very nicely in this post (http://www.FutureQuest.net/Community/SiteOwner/) where he says:
Symlinks are treated as if they were real files in the directory they were created in. If you link www/index.html to www/home/index.html, that would be the same as creating a real file www/index.html.

So, by moving your files outside the cgi-bin directory, but creating a symlink that has the exact same name as though you had placed the files as the script recommended, you've essentially got the same set up.

You can test this for yourself as follows:

Create some sample html file and put it outside your www directory, but create a symlink to it inside the www directory. You will find that you are able to access the file easily with your browser. Delete the symlink, and that is no longer true.

Hope this helps,

[sheila]

By the way, I didn't address all of your issues. Having include files and data files inside the cgi-bin doesn't sit well with some people, as there is a URL that leads to such files, and so the files are theoretically accessible by a browser.

If you feel safer moving the files outside of the cgi-bin directory, by all means do. However, FutureQuest has the cgi-bin configured so that all files in the cgi-bin are treated as executable. Therefore any file in the cgi-bin that is not an actual executable file returns a 500 Internal Server error when the URL that would lead to that file is requested. (This is also why image files will not work from within the cgi-bin at FutureQuest.) I personally do keep data files in my cgi-bin and feel quite safe about it. YMMV.

Hope this helps,

[Jake]

Hello Sheila,

Thank you so much for both replies. It's nice to have the cool "Site Owner" status now! 8}

Sorry to have taken almost a week to reply with thanks...the information is very appreciated.

So, by moving your files outside the cgi-bin directory, but creating a symlink that has the exact same name as though you had placed the files as the script recommended, you've essentially got the same set up.

darn.

FutureQuest has the cgi-bin configured so that all files in the cgi-bin are treated as executable. Therefore any file in the cgi-bin that is not an actual executable file returns a 500 Internal Server error when the URL that would lead to that file is requested. (This is also why image files will not work from within the cgi-bin at FutureQuest.)
I've read about how on some hosts images don't work in the cgi-bin but I didn't really ever think of it as a security feature, just a way to keep the cgi-bin sacred (a folder made only for executables). It's cool to know that the error extends past just images and html files. I feel safer already!

"...the permissions of the symlink are meaningless: it is the permissions of the target file that determine whether a user has the access to it." - from http://www.labs.redhat.com/gug/users-guide/symlinks.html (See below for the whole document.)
This is what originally sparked my interest, and gave me the idea.
A user can't get to my file if it's out of the web document tree (/cgi-bin and /www). My line of thinking was if I symlink to the file, the server would realize that it's not in the web document tree and it wouldn't allow access to the file. But I forgot one detail:
...there is a URL that leads to such files, and so the files are theoretically accessible by a browser.

This is more of a thank you and may hopefully be of use to someone in the future. The issue has moved from my high-priority list to my low-priority list c/o the Internal Server Error.

I do have one more curiosity, though.

You can test this for yourself as follows:

Create some sample html file and put it outside your www directory, but create a symlink to it inside the www directory. You will find that you are able to access the file easily with your browser.
This makes sense to me.
But substitute the www directory with the cgi-bin. Now try that. It gives the Forbidden error message. Shouldn't it be an Internal Server Error? A symlink to a file inside the cgi-bin (both the symlink and the file are in the cgi-bin) gives an Internal Server Error. Same with a real file in the cgi-bin gives an Internal Server Error. But move the real file out of the cgi-bin and you'll get Forbidden. Any ideas on why it's a different error message?

Again, thanks for all your help (I can sleep easier now) :QTsnore: ,
Jake




For those who would like to read the whole file:

http://www.labs.redhat.com/gug/users-guide/symlinks.html
"Symbolic links

In addition to regular files, UNIX also has special files called symbolic links (or symlinks for short). These files do not contain any data; instead, they are just "pointers", or "shortcuts" to other files. For example, sasha can have a symlink named ft.txt pointing to the file papers/fieldtheory.txt; this way, when a program tries to access the file ft.txt, the file papers/fieldtheory.txt will be opened instead. As you can see from this example, the symlink and the target file can have different names and be located in different directories.

Note that deleting, moving, or renaming the symlink file has no effect on the target file: if sasha tries to delete the file ft.txt, it is the symlink that will be deleted, and the file papers/fieldtheory.txt will remain unchanged. Also, the permissions of the symlink are meaningless: it is the permissions of the target file that determine whether a user has the access to it.

Symlinks can also point to directories. For example, on the GNOME FTP server (ftp.gnome.org), there is a file /pub/GNOME/stable/releases/october-gnome, which is actually a symlink to directory /pub/GNOME/stable/releases/gnome-1.0.53 — as one would expect, since "October GNOME" is just another name for 1.0.53 release of GNOME."