Feature request: Home folder write permission

When I log in as user with

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.

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.

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.

I can confirm that then indeed I can rename the conf folder. I think it would be safer then when the conf folder (and others like these) would not be in the home directory.

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?

No response?

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.