Users can delete /public_html

You can't really prevent them from doing that, except for changing the owner of that directory. As long as they're the owner, they can change the access rights to whatever they want.

I'd say: if they delete the public_html, it's their problem. :) They're vserver owners = admins, thus they have the corresponding rights and responsibilities.

Also, they can easily recreate the directory, and the Apache warning is just that: a warning. It does not negatively affect its operation or other vservers.

Yeah, as Locutus said, being as it's their home directory, they can delete any of the directories in their homedir. However, they really shouldn't, as that might cause their stuff to not work right :-)

If you have a user who's very into deleting things, you might consider creating a new FTP account for them that's locked into their public_html dir.

You can do that by going into Edit Mail and FTP users, and click "Add a website FTP access user.".

Then, just be sure that in Limits and Validation -> FTP Directory Restrictions, that there's a rule setup to lock FTP users within their home directories.

-Eric

If you have a user who's very into deleting things

That one made me chuckle. ;) BOFH anyone?

Still, as I said, I don't really see a problem with the server owner being able to delete the public_html dir. (Except they're completely oblivious to what that directory is and what they're doing, in which case they shouldn't be having access to the server at all, neither above nor below the public_html ;).) If they do so, they can easily recreate it, and even while it's gone, nothing else but their own website will be broken.

Being able to delete the contents of that directory is what I'd really be concerned about in case of that type of users. ;)

if the user has access to webmin they can still delete things above /public_html.
Before Jamie came with a fix, users could delete the /logs directory which was a big problem for the server...

There will always be users with less knowledge, in those cases I made some files in the /etc/skel which says:
DO_NOT_DELETE_ANY_FOLDERS_HERE
UPLOAD YOUR WEBSITE INSIDE THE PUBLIC_HTML FOLDER
The files are copied inside their environment
It's silly but apparently necessary to avoid extra support tickets.

OK .... I set all the virtual server FTP restrictions to look like this under Validation and Limitations: FTP Directory Restrictions:

active (on)

X

X only server myDomain.com X Virtual server's home directory

but if I log in via FTP as the admin owner of myDomain.com

I can still see all the way to root... and not only that, I can actually open and read files owned by other users, all the way buried deep in /opt/web/lib/ which are owned "root" or "Andre"... i.e files that i do not own....but:

if I go to /home/someOtherDomainUser/

I can't see any files. and the restriction is operative; so, that's good, but should not the restrictions apply to all directories outside of

/home/myDomain/

I would think it especially important that these users not be able to see all the way down.

of course most files are 644 rw- r-- r--

So I guess therein lies the conundrum. since "others" is set to read... anyone can read it. but if you can lock out the user from /home/someOtherUser/ (I cannot even get a file listing) why can't we do that for all directories outside the /home/myDomain for that particular user?

Howdy,

Yeah, it doesn't matter who owns the file... they key is to see if the "Global Read" permission has been enabled or not, as you mentioned above.

If a user can read a file owned by another user, that's just a sign that the file and directory it resides in has been setup as world readable -- meaning, any user would be allowed to read it if they want.

If you want to prevent an FTP user from browsing the server, you can do so by locking them into their home directory... you can do that in Limits and Validation -> FTP Directory Restrictions.

However, that doesn't change the global read permissions on the files/dirs on your server, that only prevents a user from wandering around when connecting via FTP.

A user uploading a PHP app into their web space (ie, a PHP-based file manager) could browse files on the filesystem using that. So if you don't want all users browsing in "/opt/web/lib/", you'd want to change the permissions there to prevent that from happening.

-Eric

But the puzzle for a naive admin like myself is: why would a plain vanilla CentOS5 Web set up, set default permissions for system files to 644 rw- r-- r--

which give global permission to read any file? My assumption is, "if you want the system to run, then all users need to be able to read these files."

So, OK, I will jail in the current users to their FTP home directories.But as you say, this does not lock out anyone who sets up a filemanager widget in their space. Does this not expose all kinds of "proprietary" data (config files, htpassword files etc.) on the box to all the web users? I can't imagine that CentOS really is intended to be that vulnerable, or perhaps it is not a vulnerability at all.

I can test chmod -R 640 /opt and turn off all permissions for global-others and see if anything breaks for the "plugins" we have put there, but all sys files? But it seems like a dangerous thing to set all the system files to rw- r-- --- e and not allow anyone other than the owner or group to read even if I do that for /opt and it doesn't break anything I worry this would break CentOS5 completely. I'm way out of my depth at that level of file administration.

Only files that contain no security-relevant information are set world-readable by the OS installer, you can be sure about that. Any other files that are installed by users or vserver owners (especially stuff in their home directories) are their own responsibility to set up correctly.

And you should be careful about changing the file permissions globally in /opt etc. You might break a number of things if users cannot access vital files like executables or config settings anymore.

If, as you outlined, the "Restrict FTP" function does not work as intended, i.e. the FTP user should see the web server home directory as "/" and not be able to move up in the host's file system tree, there's something wrong with your setup or maybe the FTP server was not restarted correctly.

I am quite certain I set the FTP directory restrictions correctly Active --checked Only Server "myDomain.com" selected Virtual Server's Home Directory selected

The above for all domains. Though each time I get an additional unselected entry at the bottom of the list. I presume you this for now restrictions and if it is unchecked it has no effect.

Stopped and started the FTP server

But I can still traverse /

and read any file anywhere with global set to read:

SSH_FXP_READDIR drwxr-xr-x 2 root root 4096 May 8 2008 disk2 [SFTP[4096,0,0,16877,1210286214]] drwx------ 2 root root 16384 May 8 2008 lost+found [SFTP[16384,0,0,16832,1210282785]] dr-xr-xr-x 211 root root 0 Feb 8 11:09 proc [SFTP[0,0,0,16749,1297192156]] drwxr-xr-x 2 root root 4096 Jan 31 04:05 bin [SFTP[4096,0,0,16877,1296475553]] drwxr-x--- 21 root root 4096 Jan 12 00:30 root [SFTP[4096,0,0,16872,1294821006]] drwxr-xr-x 2 root root 4096 Mar 29 2007 srv [SFTP[4096,0,0,16877,1175187612]] drwx------ 5 root root 4096 May 12 2008 Maildir [SFTP[4096,0,0,16832,1210611220]] drwxr-xr-x 2 root root 4096 May 8 2008 selinux [SFTP[4096,0,0,16877,1210282811]] drwxr-xr-x 26 root root 4096 Feb 8 11:09 .. [SFTP[4096,0,0,16877,1297192177]] drwxr-xr-x 2 root root 4096 Jul 8 2008 media [SFTP[4096,0,0,16877,1215558066]] drwxr-xr-x 27 root root 4096 May 10 2008 var [SFTP[4096,0,0,16877,1210449522]] drwxr-xr-x 30 root root 4096 Feb 17 17:42 home [SFTP[4096,0,0,16877,1297993364]] drwxr-xr-x 2 root root 4096 Mar 29 2007 mnt [SFTP[4096,0,0,16877,1175187612]] drwxr-xr-x 2 root root 4096 Feb 9 2008 misc [SFTP[4096,0,0,16877,1202552243]] drwxr-xr-x 8 root root 4096 Dec 5 15:08 opt [SFTP[4096,0,0,16877,1291590507]] drwxr-xr-x 2 root root 4096 Dec 2 14:39 postgresql [SFTP[4096,0,0,16877,1291329557]] drwxr-xr-x 106 root root 12288 Feb 19 09:26 etc [SFTP[12288,0,0,16877,1298136389]] drwxr-xr-x 26 root root 4096 Feb 8 11:09 . [SFTP[4096,0,0,16877,1297192177]] -rw-r--r-- 1 root root 0 May 8 2008 .autorelabel [SFTP[0,0,0,33188,1210283218]] -rw-r--r-- 1 root root 0 May 29 2008 .htaccess [SFTP[0,0,0,33188,1212094176]] drwxr-xr-x 11 root root 0 Feb 8 11:09 sys [SFTP[0,0,0,16877,1297192158]] drwxr-xr-x 10 root root 3760 Feb 9 07:27 dev [SFTP[3760,0,0,16877,1297265259]] -rw-r--r-- 1 root root 0 Feb 8 11:09 .autofsck [SFTP[0,0,0,33188,1297192177]] drwxr-xr-x 3 root root 4096 Dec 26 2009 backups [SFTP[4096,0,0,16877,1261873122]] drwxr-xr-x 14 root root 4096 Jan 31 04:05 lib [SFTP[4096,0,0,16877,1296475548]] drwxr-xr-x 4 root root 1024 May 10 2008 boot [SFTP[1024,0,0,16877,1210431546]] drwxrwxrwt 7 root root 69632 Feb 19 09:27 tmp [SFTP[69632,0,0,17407,1298136475]] drwxr-xr-x 15 root root 4096 Dec 2 14:40 usr [SFTP[4096,0,0,16877,1291329655]] drwxr-xr-x 2 root root 12288 Jan 31 04:05 sbin [SFTP[12288,0,0,16877,1296475552]] SSH_FXP_READDIR

But, no user can see can see any content in /home/otherUser/

directories, (but he can see all the users, but not the content in those folders)

You might want to check the ProFTPD config file directly, to see if your desired settings have correctly been applied there.

As for being able to read files which are set to world-readable I already wrote my "share of wisdom". About being able to see other users' directories (even if not being able to traverse into them): well, that's another "restriction" of using Linux for shared hosting purposes.

While in FTP, as I pointed out, restricting users to their home does work - when configured correctly, the same is much harder to achieve in SSH (and in PHP file browsing scripts that users might install), hence it is not really feasible to try and hide the names of other home directories from vserver owners - except you deny them the right to use SSH or install PHP files.

If you use proftpd and centos you should also read this :-)

http://www.virtualmin.com/node/16522