> Please cut-n-paste the output of the following command: > > ls -ld /home/sites/home
[admin admin]$ ls -ld /home/sites/home drwxr-xr-x 7 admin home 4096 Mar 13 11:15 /home/sites/home which is CHMOD 755 and absolutely normally. Only "admin" or "root" should be able to cd into that /home/sites/home directory. User alfred against it should receive a Permission Denied response as soon as he tries to cd /home/sites/home [admin admin]$ ls -ld /home/sites/site1 drwxrwsr-x 7 alfred site1 4096 Feb 10 17:30 /home/sites/site1 drwxrwsr-x has been created by the Cobalt GUI system. I don't understand this setting. Each "site" comes with it's own group. The group of site1 is site1, the group of site2 is site2 ... and so on. --Dave > > At the beginning no siteadmin or siteuser was able to "cd" into > > each site directory. Permission denied what is the default > > on Linux systems normally. > > I'm not sure I agree with this. A non-privledged user can cd > into any directory for which they have permission, based on user > or group id. The problem with web sites is that the webserver > must also be able to read files in the directory, else it will > not be able to serve the page. > > One of the solutions I've seen is to create a separate group for > each user: > > In /etc/passwd: > username:passwordstring:12345:12345:User's Name:$HOME:$SHELL > In /etc/group: > username::12345:username,webserver > > Thus, the web server can cd into everyone's directory (subject to > .htaccess and httpd.conf restrictions), but individual users cannot > cd into one another's directory (assuming they've chmod'd their > files to u+r[w],g+r,o-rwx) > > > But now every siteadmin/siteuser is even able to enter into > > /home/sites/home although ./home is owned by admin. > > Please cut-n-paste the output of the following command: > > ls -ld /home/sites/home > > If the permissions are group or world readable/executable, then > that is the 'correct behavior' (due to config/setup error) > > > That's not normally and just a Telnet/SSH problem :-( > > I suspect if you hooked up a terminal to the serial port, you'll > get the same behavior. What you're seeing here is the standard > behavior of any *nix system. > > > Websites against it can be protected by .htaccess > > And exactly that's the real problem because .htaccess > > is not working with SSH. > > SSH does not respect .htaccess. .htaccess is only for web > servers. ssh has a host of other config files to limit/permit > specific users, machines, commands, etc. > > > On the other hand it's not possible to disable SSH access > > for a domain or user by the Cobalt GUI. Shall I enter > > /bin/false manually ? > > Please consult your ssh documentation - specifically, man sshd > and look for the string "AllowUsers". And yes, giving a user > a shell of /bin/false will work just fine as well, but it doesn't > scale well. > > > As we decided to purchase Cobalt server we expected a secure, > > good working and easy to handle server system. > > > > Now I have to do a lot of work manually and the Cobalt eMail > > support looks no longer available. > > Anyone who tried to sell you any sort of server (web, email, > whatever) by saying that you don't need to understand the basic > fundamentals of the operating system and bundled programs is > doing their company a disservice. > > Anyone who tries to administer any sort of server w/o the same > basics under their belt is due for a rude shock. > > tim > > -- > Mechanical Engineers build weapons. Civil Engineers build targets. > _______________________________________________ > cobalt-security mailing list > [EMAIL PROTECTED] > http://list.cobalt.com/mailman/listinfo/cobalt-security > _______________________________________________ cobalt-security mailing list [EMAIL PROTECTED] http://list.cobalt.com/mailman/listinfo/cobalt-security
