I want to submit this to the subversion repo.. I find this very useful, I mostly have these set under the advanced menu that only admins can do but basically what it accomplishes is a) Establishes a Unique ID for Shell Users separate from the main website b) Establishes a Group friendly policy on the website. (so a shell users added in the group of the website can also edit files on the website.) The configuration is very simple, I have a checkbox in the options section under the Websites for Group Friendly and a Checkbox for Unique ID under options for shell users. Using this configuration you can also control regular shel users in the ISPConfig that are not directly tied to the website. Check with Till/Falko to make sure this is an okay mod to add, I want to refine it a little more before I commit or give a patch. But my end goal is simply better Shell User/Webdomain management, possibly even just attaching some shell users to the client itself.
Where is the benefit of this solution compared with the current setup? Currently the shell users of the website can edit the website files, as all shell users share the same userid. If the users have a different userid, you will have to setup separate home directories for the users and seprarate jailkit jails etc., this will prevent the users from accessing the website files as they will not be able to leave their jail. For security reasons, the goal was that group write permissions are not required for a website. If we change that, a website that has mod_php enabled can be used to hack all other websites or if there is a hack e.g. in phpmyadmin, the hacker can take over all websites then.
Well for my setup in particular, I need the control panel to manage shell accounts as well to include shell services. And one particular account may have multiple shell users attached to it, and they have their own stash of files in their own home directory and not allow the other shell users access to their files. My server setup in particular, and I'm sure there may be others, offers more than just web-hosting accounts. And the shell user accounts are not jailed so they have access to the development tools that are on the server. I understand that offering non-jailed shell users is a security risk in some environments. Though the more I think about this, the more I"m thinking I should move my system to an ACL permission scheme for my setup. In doing that, perhaps have a multi-select box on the web-domain part specifying in the domain that also have write access to the website on the user level. I'd like to incorporate my setup into the actual ISPConfig setup so I won't have to constantly take my patch in and out as versions increase. Perhaps offer it on a special server configuration security level?
As you offer shell user hosting, then this makes sense indeed. I havent thought about that option. That might be a good place to implement it. Basically we could do a setting on a per website basis as well as you suggested in the first post, this would be more flexible on one side but on the other side, it would be more likely that a user changes this setting for a exsiting web and I guess it would be a real mess if we have a website with e.g. 10 jailed shell user where someone switches this setting and we have to find a way to migrate the security system then. Maybe it is even nescessary to block this setting after a web is created, what do you think?
As you offer shell user hosting, then this makes sense indeed. I havent thought about that option. That might be a good place to implement it. Basically we could do a setting on a per website basis as well as you suggested in the first post, this would be more flexible on one side but on the other side, it would be more likely that a user changes this setting for a exsiting web and I guess it would be a real mess if we have a website with e.g. 10 jailed shell user where someone switches this setting and we have to find a way to migrate the security system then. Maybe it is even nescessary to block this setting after a web is created, what do you think?
That is the current setup I have, it is an option settable under the "advanced" limits menu that only admin can set. I don't want customers on their own deciding to allow this behavior.
Ok, then feel free to upload the changes to svn. I think we should add is a check that throws a error message when a administrator tries to change this setting when there is already a shell user for this website. And in case that jails wont work anymore with that setting, we might have to add a warning or make it impossible to select that setting if jailkit is selected for that client in the client settings.
I think it would be possible to integrate migrating jailed users to/from this type of setup. My general idea is though.. Shell users like this belong in the /home directory, whereas jailed users belong much closer to the website. I'll experiment with this more before I actually push it upstream. I think its important for admins themselves to be able to change this setting if need be, so I wouldn't push a finished versions that can't properly go both ways by an Administrator.
Maybe it is a option then to have two types of shell users by adding a switch in the shell user options like "website shell user" and "general shell user" or however we would name then. So a admin can add shell users with access to the website then and additionally have shell users in /home/... for shell or development tasks. So we dont have to touch the current shell user system and just implement a second type of users which dont interfere with the current setup.
