![]() |
Unique Shell ID & Group Friendly Websites
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.
Quote:
|
As you offer shell user hosting, then this makes sense indeed. I havent thought about that option.
Quote:
|
Quote:
|
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. |
Quote:
|
| All times are GMT +2. The time now is 07:37. |
Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2013, vBulletin Solutions, Inc.