Private non-http files

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.

I think that should address your main concerns. Granted it is not a *total* fix:

1) 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.

2) Of course, you *do* realize that *root* can "see" everything - encryption is your only protection against this on a shared server. wink

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. wink

--rlparker

In reply to:
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 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". wink

--rlparker

In reply to:
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".

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?

In reply to:
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?

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. wink

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