I’d like to know the general approach to ensuring that our non-http space is not accessible to our fellow DH shared host friends here who may be using cd/ls to nose around the server. I’d like to use our extra disk space for extended offline storage via FTP. Sure, I can zip/rar and password file collections, but in addition to that is there any highly recommended chmod strategy or something similar? I don’t want people to open my files, see my files, or even see my directories.
Thanks!
If you don’t need http access to them, just set the directories and files to 700 permissions. Other DreamHost users can no longer list the contents of /home, so the cannot discover your “user” directory name in that way.
–rlparker
Done. Fantastic - thanks again!
Does it also work to put the files outside of the web directories of any sites you host? You know, in a directory directly off of the user home directory?
I know that scripts could access these files but I’m pretty sure that you can’t “…” your way around the directory structure in the path part of a url.
Free unique IP and $67 off with code [color=#CC0000]LMIP67[/color] or use [color=#CC0000]LM97[/color] for $97 off. Click for more promo code discounts
I think that should address your main concerns. Granted it is not a total fix:
If you somehow reveal your username path (an ill-advised displayed error message, etc), another user on your same server could still get a list of your directories, but they would not be able to get a listing of the directory contents or be able to read/modify any of the files in the directory.
Of course, you do realize that root can “see” everything - encryption is your only protection against this on a shared server. 
To a great degree, “security” always involves some trade off between functionality and risk. There is always the potential for any file you store on another’s machine to be read by the machine owner unless sufficiently encrypted, so you should plan accordingly if your data is sensitive enough to you to warrant concern about that.
–rlparker
I think it is accurate to say that “it works” to a certain degree for visitors using a browser, and you are correct that they will not be able to move “uptree” by manipulating a “standard” url.
That said, you are also correct that scripts can do this and, under suexec, that makes it particularly important that scripts are “hardened” to prevent direct url manipulation that could result in allowing them to manipulate files “uptree”.
The OP’s stated concern was “ensuring that our non-http space is not accessible to our fellow DH shared host friends here who may be using cd/ls to nose around the server”, which I took to mean that he was concerned about ftp/ssh based “exploration”.
–rlparker
Ah yes, I didn’t make that connection and thought the concern was just for people url-exploring.
So is it true that for the default umask that other users on the server can view the files one creates as long as they can guess the full pathname?
Free unique IP and $67 off with code [color=#CC0000]LMIP67[/color] or use [color=#CC0000]LM97[/color] for $97 off. Click for more promo code discounts
I don’t believe that is still the case. That was the case at one point in tme, but it is my understanding that they changed that.
For my servers, that is certianly the case - I could do it in the past but can’t do it any longer.
Note that irrespective of the default umask, you could/can always set the permissions on your files as appropriate for your security concerns - the problem was that many didn’t bother. To me the real problem was being able to list directory contents. For instance, if a site was running mod apache, or a user allowed sufficient permissions, you could run a script on the server to access/manipulate some of those files if people were careless - and you could explore the dirs to find “targets”.
Now, you can’t list the contents of dirs to facilitate the exploring, which helps considerably.
–rlparker