shell accounts

  • Hello! :-)


    (little introduction, if too long just skip to last paragraph)


    I'm current ispcp user. In next 2 months I'm changing the server and to be honest I'm looking around for something better (don't exactly like where ispcp is going, their updates and few breaks in database data causes breaks in config files..).
    I like what I see on your forum and trac, using Zend (or just any kind of framework), deciding that email passwords can be stored in db as clean text due to many reasons etc etc.
    Also - I just love the plugin system. Looks like (if not now then soon, after adding few more events in the code) I could do some enhancements without changing i-mscp system files.:D


    I'd also like to contribute, but this one later. For now I have one, major for me, question. What do you want to do with current structure of accounts, account names and shell access?
    I only saw somewhere in the forum that someone posted it as an idea and in the next reply someone else agreed with him ;)


    Now under ispcp I have some weird set of sudo commands for manually added users to give them some commands to edit, manage their vhosts ;) So this thing is pretty important to me.
    Can you tell me something more? Do you have something planned (if yes, what? and would you like to take some help on this one?), more-less due date for it?

  • I think we may start to thinking about some basic general idea how to resolve shell access.
    Some users wants to have restricted/chrooted shell, some not - but I think we can leave it for later and now focus on structure and permissions.



    Some ideas from the irc:


    1. reseller group
    User files are owned by username:reseller-group.
    To reseller group belongs some reseller and admins. Not the user (to avoid user reading other user of the same reseller files)


    cons: When user will upload files via the ftp - we can set correct group in ftp config. But created files in shell will be owned by usergroup, not reseller.. So some feature needed to "reset permissions" by the reseller when needed..



    2. sudo
    Maybe we can use sudo for it? User files are owned by username:usergroup, reseller by resellername:resellergroup - but reseller is able to type "sudo my-user-1" and "switch" into user account - like in the panel.


    cons: It's dangerous, but from the other hand history shows not so many detected bugs: http://www.sudo.ws/sudo/security.html and they're fixed pretty much in every distribution security list- which is better than some unsupported and rare software.


    pros: reseller will not only gain access to user rights but also to user processes



    Any thoughts?

  • I'm not a fan of the jail/chroot, I've always found it a pain to add new binaries/keep the existing ones up to date.


    This sudo bit actually interests me. Would be nice to be able to switch accounts and log it.


    Another option is to allow the reseller to add a ssh key that would be added to authorized_keys in all the domains under his control. As log as the users could also drop in their own keys, this would allow everyone to be able to get in without sharing passwords.


  • I'm not a fan of the jail/chroot, I've always found it a pain to add new binaries/keep the existing ones up to date.


    Please, leave this topic untill at least usernames will be separated from domains. ;)



    Another option is to allow the reseller to add a ssh key that would be added to authorized_keys in all the domains under his control. As log as the users could also drop in their own keys, this would allow everyone to be able to get in without sharing passwords.


    That's actually a nice idea! :)
    In case of some admin is not trusting sudo or just preffer this solution.
    So now we have 2 solutions which after very small amount of work will allow us switch from admin/reseller to reseller/user account. :-)


    kassah asked for example, for now I'm using something like:
    maur ALL=(vu2011)NOPASSWD: ALL, but I belive it can be done safer way, but since I'm using currently /etc/sudoers only for a few trusted users I wasn't spending a lot of time on it. ;)


    So if anyone will not have some better idea we can start with permissions for user accounts without any magic like shared group for reseller. ;)


  • 1. reseller group
    User files are owned by username:reseller-group.
    To reseller group belongs some reseller and admins. Not the user (to avoid user reading other user of the same reseller files)


    cons: When user will upload files via the ftp - we can set correct group in ftp config. But created files in shell will be owned by usergroup, not reseller.. So some feature needed to "reset permissions" by the reseller when needed..


    @maur
    i hope i'd understand it correct...
    You want to share some files for user the users of the reseller.
    So you can create some folders with a sticky bit.. You change the owner of this folder to reseller:reseller_users...
    The advantage is that only the owner of the file, the owner of the folder and root can delete this file.
    If a user creates a file in this folder the file will be set by the user who creates this file but other users of the reseller_users group can read this file.


    Is it that what you want?


  • What I want - secure permissions (users don't see each other files and can't read them)
    but reseller1 (owner of for example user1) can have access in some way to all files of user1.
    (so he can help him somewhen, or manage something, or whatever)