multiple users for msm

Josh's Avatar

Josh

Dec 03, 2012 @ 07:28 PM

I am trying to get msm to work with multiple users. All the users are in the same group. I am still having some issues and I think it is part of the code that is causing it.
I have set the owner of msm to root:mcusergroup
I have set suid on msm.

I think the issue is within the as_user function, but I am not sure how to change it to check for a group instead of a user. The function starts at line 81 for me. Any suggestions would be appreciated greatly.

  1. 1 Posted by David on Dec 05, 2012 @ 05:33 AM

    David's Avatar

    Same issue post deployment.
    I am not super familiar with Linux after not using it for many years and am struggling to get around this for my secondary admins. It would help to show how you can solve for this scenario via some documentation.

    So far, I have something similar to

    adduser adminTest
    groupadd MCAdmins
    usermod -g MCAdmins minecraft (or the user you picked for msm)
    usermod -g MCAdmins myuseraccount
    usermod -g MCAdmins mytestadminaccount

    then claim over the msm folder?
    chown -R root:MCAdmins /opt/msm

    I am not sure how to set suid on msm so when I attempt to run the server with the admin account I am stuck with the following error message.
    mytestadminaccount@MYMINDCRAFTSERVER:~$ msm mymindcraftserver start
    This command must be executed as the user "minecraft" or "root".

  2. 2 Posted by Josh on Dec 05, 2012 @ 05:52 AM

    Josh's Avatar

    I am still digging through the script, but it is going to take rewriting a lot of what is already there. I will explain why

    First the function as_user calls whoami and I have found out that scripts ignore suid
    Second all of the screen commands are going to have to be changed from something like

    screen -S msm-server -X say blah blah
    

    to something like

    screen -S minecraft/msm-server -X say blah blah
    

    And to make things go as smooth as possible the script should create the .screenrc file with appropriate settings

    I haven't finished scrubbing for other things that need to be changed and I am almost positive there are at least a few. I would love you just rewrite this in a program that would respect the suid, but I am a not a good programmer and only know some scripting because I hate doing things twice.

    I will make a fork or whatever it is called on github after I figure it out and test it. I can just hope that the creator of this script sees this post and helps with the changes. Maybe even have different in-script permissions for the different users. Because I know I don't want just anybody to be able to shut my server down, but if it is down I would love to have a few more ppl able to restart it.

  3. 3 Posted by |Anthony| on Dec 06, 2012 @ 03:21 AM

    |Anthony|'s Avatar

    Screen does support multi-user sessions. And really, if we cant trust the person to responsible manage a server shutdown, they shouldn't have ssh access ;) Also, using setuid and chown can be avoided if people use ACL for file permissions.

  4. 4 Posted by josh on Dec 06, 2012 @ 05:22 AM

    josh's Avatar

    yes screen does support multi user, but the way the screen commands are written in the script you can't use it multi-user. And as far as managing server shutdown, I have already had a case where I was asleep and didn't come back up because when my scripts do scheduled restarts the shutdown then do backups and grief log rolls then it starts it again. So I have some need to allow some ppl to be able to start the server, but that is it. But I think I have lost track of what I was saying somewhere along the line.

  5. 5 Posted by |Anthony| on Dec 06, 2012 @ 07:20 PM

    |Anthony|'s Avatar

    After a good nights sleep, and a re-review of the incredible 4000 lines of bash (lol), getting msm to be truely multi-user friendly will take some modifications. As you suggested, the whole as_user() function is extremely problematic and a source of contention. Imo, that whole block and all references to it should be removed and instead it should just perform the commands as the minecraft user. Leave user management upto the servers sysadmin instead of hard coding who can issue the msm commands. I still stand by my statement "if we cant trust the person..." ;) Additionally, by utilizing access control lists, sysadmins can have a more fine-grained control on who has read, write, or execute access to specific files.

    So, the bottom line is that the current design of msm will allow ONLY the minecraft user, or the root user to have any access to the msm commands. Providing your admins a way to access the screen session should be doable (as you suggested in a different post i only just now noticed) by setting up the .screenrc file correctly. This will not enable them to restart the server via msm though. Any admin that you want to be able to start/stop/etc the mc server will need to have sudo access, or be able to su as minecraft. This is a security problem as far as I'm concerned.

  6. Support Staff 6 Posted by Marcus Whybrow on Dec 06, 2012 @ 09:33 PM

    Marcus Whybrow's Avatar

    Hi all, I've been following your conversation and here's my view:

    When I was designing MSM, I read that it was a bad idea to enable multi-user access for screen sessions, as it is not very secure. To counteract this I included the as_user function to additionally allow "sudoers" to on-the-fly switch to that user the screen session is running under for interaction with the minecraft screen. Any sudoer can use MSM, then, as you intend to.


    That's the past, but what about the future! I agree, it would be a whole let better for MSM to get out of the way of native permissions and let you decide how things are protected.

    Maybe we move from creating all files using a single username, to using a single group, and leave the username as whoever called the command. That would work for accessing files MSM manages, but what about interactions with screen?

    Inherently screen wants to restrict things to a single user, and doing anything else is a massive pain. It can be done, as you know, with some security implications, by maybe adding this to the MSM installer:

    chmod u+s /usr/bin/screen
    

    Screen sessions can be made to allow access from other users using:

    <ctrl+a>:multiuser on
    <ctrl+a>:acladd user2
    

    And that could solve the problem.


    Let's, however, take the scenario that the server needs starting, and this user does not have sudo access, and is not the "minecraft" user that the server requires to run under.

    1. MSM could allow a server to be started by any user, but connecting to the screen again in the future may become difficult to keep track of.
    2. MSM requires the user to have permission to switch users (the su command) to the "minecraft" user in order to start the server with a pre-defined user where the screen session can be found simply.

    I have said a lot, what do you guys think? I suppose the quickest solution would be to make your other admins sudoers (if you think they can be allowed that privilege) so they can do sudo msm server start.

  7. 7 Posted by |Anthony| on Dec 06, 2012 @ 09:50 PM

    |Anthony|'s Avatar

    I would like to keep sudo access where it belongs... to sysadmins. That being said... Would it be possible to move the as_user() function out of msm.sh and into it's own file? This new user.sh file could handle checking if the calling user is listed in a users.conf file and which of the msm commands the user is allowed to access (we don't want just anyone to be able to create a new server). Additionally, having the msm.conf file living in /etc requires having each of the calling users to be able to access it there. I personally feel that it would be better all to have the msm and minecraft files live inside /home/minecraft. Using access control lists is a much better way to manage who can read, write, and execute a particular file. In fact (you are not going to like this), considering the benefits that acl offers, breaking the massive msm file down into individual modules would allow sysadmins the flexability to easily allow or deny specific msm commands to be usable through acl. The resulting trimmed up msm file would really only then need to call the traditional start/stop/restart functions that the init.d files do. Every other function could be an individual module. That's a massive re-write... i know :/

  8. 8 Posted by David on Dec 07, 2012 @ 03:04 AM

    David's Avatar

    I would prefer not to give out screen sudoer capability.

    Is it not possible to tail the log on the top, and similar to the actual console submit commands which get executed similarly to cmdlog, which you then catch in the tail? were probably talking compiled code for this but if you are just passing msm commands via console and tailing the log, would that make it more possible? crosses fingers

  9. Support Staff 9 Posted by Marcus Whybrow on Dec 07, 2012 @ 03:17 AM

    Marcus Whybrow's Avatar

    They only way to execute a command on the Minecraft server is to type into the screen session and hit enter. You can't do it by writing to the server.log file. The code which handles command execution is the Minecraft jar itself, which yes, is compiled by Mojang.

    Essentially, if we want to send commands to the server, we have to gain access to screen (as far as I know.)

Reply to this discussion

Internal reply

        No formatting (switch to Markdown)

          You can attach files up to 10MB

            If you don't have an account yet, we need to confirm you're human and not a machine trying to post spam.

              Keyboard shortcuts

              Generic

              ? Show this help
              ESC Blurs the current field

              Comment Form

              r Focus the comment reply box
              ^ + ↩ Submit the comment

              You can use Command ⌘ instead of Control ^ on Mac