Feature request: Home folder write permission

  • When I log in as user with

    Code
    su - username

    and try what I often do, namely start mc (midnight commander) then I get permission errors that the user (the application started by the user) is not allowed to create its configuration folder. I then I discovered that the user has no write permission there.


    When this was consciously chosen for a important reason, then my suggestion is to have the home directory where is usually is at /home/username and there you can allow the user to write, without interfering with that important reason. With a symlink you could then bring /var/www/username in the home folder for convenience.

  • I'm sorry, but it isn't that simple. :(
    As soon as you use suPHP or suExec (which should be mandatory on shared hosting environments), the security layer checks that the requested resource (eg. a PHP script) is within the user's home directory.
    So, when requesting for instance "/var/www/web1/htdocs/index.php", the user's home directory must be anything below /var/www/web1/htdocs.
    Additionally, many configuration files are created where the user may not get any write permissions. So the home directory must remain read-only (to protect the other folders).


    Alternatively, you may prepare the configuration folders for the desired applications manually, eg:

    Code
    mkdir /var/www/web1/.ssh
    chown web1:web1 /var/www/web1/.ssh


    Would this be ok for you?

  • After your explanation about suPHP, I understand that a symlink is not a solution, but you could allow home folder read-write.


    There is no further need to protect the conf, logs and stats folder, because they are not owned by the user and have only group read access. Furthermore the home folder is owned by the user so the user him/herself can change the permission to read-write. I see therefore no reason why LiveConfig won't set the initial home folder permission to read-write for convenience sake.

  • Zitat

    Furthermore the home folder is owned by the user so the user him/herself can change the permission to read-write.


    This is not correct. To change the permissions of a folder, you need write permission in its parent folder.
    This is also the reason why the user must not have write permissions to his home folder - otherwise he could for example rename the "conf" folder to "conf.old" (no matter who actually owns this one!) and substitute it by a new conf folder.
    Just try it out. :)


    So you need to be really careful when planning write permissions to users.

  • In fact I tried it out before writing. To reproduce:


    • Created a new customer and in it I created a new subscription with a hosting plan that has ssh enabled called testaccount
    • As root I created the /var/www/testaccoun/.ssh/authorized_keys with my public key. Note the missing "t". The entered subscription ID was truncated without warning. The entry field should not allow more characters to prevent this and avoid confusion.
    • I logged in successfully with ssh testaccoun@mydomain.com
    • By default you end up in the home directory /var/www/testaccoun. I executed:

      Code
      $ chmod u+w .
      $ ls -al
      total 28
      drwxr-x--- 7 testaccoun www-data   4096 2012-09-27 15:03 .
      drwxr-xr-x 7 root       root       4096 2012-09-27 15:01 ..
      drwxr-xr-x 2 testaccoun testaccoun 4096 2012-09-27 15:01 htdocs
      drwxr-x--- 2 www-data   testaccoun 4096 2012-09-27 15:01 logs
      drwxr-x--- 2 testaccoun testaccoun 4096 2012-09-27 15:01 priv
      drwx------ 2 testaccoun testaccoun 4096 2012-09-27 15:04 .ssh
      drwxr-x--- 2 testaccoun testaccoun 4096 2012-09-27 15:01 tmp



    As you can see the single dot (the home) has now rw permission.

  • Well thanks (ironical), now with release of the new version of LiveConfig, the home folder is owned by root and write protected. This makes it impossible for the users to even manually create the folders that applications create automatically (.bash_history, .selected_editor, .mc folder, .ssh folder, .fishsrv.pl, .drush, drush-backups, .cache) , making the ssh console connection really very user unfriendly. It will make the use of drush, the Drupal configuration tool, impossible without extensive changes as root. Therefore the feature request remains valid.


    Taking into account your considerations I would reformulate it, to please separate from the home folder all that the user should not touch. That way there is no problem making the user folder writeable and owned by the user, which is the default in all Linux systems when a new user is created. When you go away from that default, you only seek problems.


    I think the goal of LiveConfig or just any Hosting Control Panel should be that it is least intrusive as possible on the default behaviour of the operating system and in this case it is annoyingly intrusive.


    Do you at all agree that a Control Panel should be least intrusive as possible?

  • If i am not mistaken i have see a german post this week where was told that the rights of the home folder should not be touched.
    The reason was that if the user can create folders/files within his homedirectory, it would be possible for him to manipulate the httpd/php.ini configurations files etc.


    EDIT:
    Ive found the mentioned thread
    http://www.liveconfig.com/de/f…ds/550-SSH-und-Userrechte

    - LiveConfig 1.6.0-r2052 (Inaktiv) :: BETA: 1.6.1 - r2142 (Inaktiv)
    [HR][/HR] - CentOS 6.3 x64[HR][/HR]- Apache 2.2.15 - PHP 5.4.12* - mod_suphp 0.7.1** - MySQL 5.5.30*
    - Postfix 2.6.6 - dovecot 2.0.9 - Clamd 0.97.6** - clamav-milter 0.97.6**- postgrey 1.34**
    - vsFTPd 2.2.2 - AWStats 7.0**
    * Aus dem REMI-Repository :: ** Aus dem rpmforge-Repository

    Einmal editiert, zuletzt von webby ()

  • So the answer is that "LiveConfig" will not change the configuration structure and therefore we will need to implement this work around?


    That, i.m.h.o. is not according to LiveConfig's claim (from your frontpage):

    Zitat

    Minimal-invasive


    Server configuration files are modified as conservative as possible. Their structure remains in the way it is typical for your distribution.


    In standard Linux you can change everything in your home directory. The home directory is yours and you determine what you can do with it and it is always under /home/. That is the idea of ownership in Linux. In that context changing location and making it read-only is intrusive. The way it is implemented makes it impossible for the user to create off-site folders, that in some web applications are needed to create a secure file system. These are all restrictions that need to be "worked around" if you let LC be as intrusive as it is at the moment.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!