MineOS-ruby authentication ideas

Development
1

Hey all, recently I’ve gotten back into my programming kick and I’m putting some good, serious effort into completing and deploying MineOS-ruby.

This is long, long, long overdue, since I first started this about 2 years ago and then put it on a hiatus. However, some of the more recent posts to this discourse made me think: “hey, remember that time I made a ruby-based mineos and it solved, like, all the issues I’m seeing show up nowadays?”

Well, I’m glad to announce that the code I wrote 25 months ago still holds up and after a very strong re-read of the code, I feel confident it was engineered well enough to continue today.

I’m now a few dozen commits into modernizing this codebase with all the features I was hoping to back in the day.

I have the S3 interface working nicely (self-hosted is currently the plan) and it seems to work wonderfully for the sake of downloading/storing server profiles and server archives.

I have the hq/worker model working nicely, meaning there’s a server that handles all inbound requests and dispatches it to the appropriate worker (which very well could be a single-machine setup). I have the AMQP messaging system in place (for reliable delivery/requeuing of all requests as necessary).

This all, of course, is just self-adulating name-dropping. While administrators will have to install these lightweight apps, its operation will be largely transparent and admins will not need to learn them in order to use this iteration.

Where I’m at:

  1. ruby interface for Minecraft Jars and Phars complete. I’ve designed it in a way that means I’m a stone’s throw from being able to also work with normal binaries (e.g., C/C++ servers) without any compromise: Normal binaries–like C/C++ compiled servers–are now implemented; they will be are feature-complete compared to jarfiles.

  2. HQ operates fully with REST API and websockets. The HQ works. What I need now is just the right plan for webui design; the single-host model of mineos-node is now expanded to multiple-hosts, so the webui should be updated to reflect the distributed nature of the numerous supported workers.

  3. Workers now attach directly to the I/O of the processes themselves, so this marks the end of trying to send something to the console that has gotten mangled with escaping; what you want sent to the server process will be exactly what you expect.

  4. The current object store (s3 compatible) is a lightweight binary but also includes a web interface for the uploading and downloading of archives. It’ll also allow point-and-click interfacing for a) deleting archives, b) deleting profiles, c) managing import-archives.

What I haven’t done:

  1. auth mechanism. This is 1 of the two areas I want any input offered for. Take a look at this auth YAML file.

Right now, you’ll see a list of permissions. It reads like this:

permissions:
all:
- "linux:will"
- "mojang:someotheradmin"
delete:
- "mojang:hexparrot"
modify_sc:
- "mojang:hexparrot"

On the HQ, a Linux user named will exists. When logging into the webui, it can check auth against the shadow passwords of the host. This user, will has permissions to do anything and everything for all functions for one specific (minecraft) server.

Alternatively, I know how to auth against yggdrasil (mojang official), which means you can log in with your MojangID and have, again, 100% control of the server from all perspectives. In this example, I’m whitelisting about a dozen commands “hexparrot” should be able to execute. “All” is all-inclusive–even for commands not listed–elsewise, hexparrot only has those perms that are explicitly listed.

Lastly, you’ll notice that console has permissions given to “mojang:lessertrustedadmin”. Realistically, having console access is still pretty strong, because they can change many options as well as stop the server (and not restart it), but more on that below.

1 Like
2

Questions:

  1. should this be something portable that travels with the server? In other words, should it be in the server’s files, like server.config is or should it exist separately, such as on the HQ?

  2. should this yaml get more and more complex, allowing even more fine-grained control of options? e.g.,

    console:
- "mojang:hexparrot"
- 
  user: "mojang:limiteduser"
  whitelist: ['give', 'teleport', 'kill', 'weather']
  blacklist: ['stop', 'difficulty', 'op', 'ban']

  1. What methods of authentication do we actually care about?

  2. Should it be database-based and therefore webui based, but then add the requirement to use MySQL/SQLite?

  3. How should servers be separated in the webui? Should users even care whether server instances are on host X or host Y? Should that only be a determination when created?

1 Like
4

I feel the auth.method has to reflect the type of installation that is running. If you have a single admin-single (minecraft)server system (well firstly MineOS is a bit like shooting sparrows with cannons, but I can see wht people use it, because of the ease of the WebUI) I do not think you need a to complicated auth system. The old root and mc system works, but perhaps with an added root or mc check (“You are trying to do this as the root user. This is not reccomended. Please use a non-root user”). This apporach probably works as long as there are only one admin.

I think that we could probably layer this like:
L1 - System admin (AKA the mc user now, has all rights on any server, uses the underlying OS for auth). May also take the role of any priviledged user bellow.
L2 - Server admin (full administrative rights to one or more servers, as defined by the system admin), may be a Mojang User . May not create new servers or adjust server hardware settings outside set parameters. Any other action is allowed(may be adjusted when we take a better loo at rights :wink: )
L3 - Server Operator (Operator on one or more servers, defined by Server admin OR System admin),may be a Mojang User. May not create, start, stop server, or restore server from archive or backup. ny other action is allowed(may be adjusted when we take a better loo at rights :wink: )
L4 -Server Poweruser. Per server right. Mojang user. Per server right. Use minecraft server op.permission-levels.

Also:
The server.properties setting op-permission-level takes care of server rights for operators, and may end up overruling settingsfrom external sources:

op-permission-level (integer 1-4)
Sets the default permission level for ops when using /op . All levels inherit abilities and commands from levels before them.

  • 1 - Ops can bypass spawn protection.

  • 2 - Ops can use all singleplayer cheats commands (except /publish , as it is not on servers; along with /debug and /reload ) and use command blocks. Command blocks, along with Realms owners/operators, have the same permissions as this level.

  • 3 - Ops can use most multiplayer-exclusive commands, including /debug and commands that manage players ( /ban , /op , etc).

  • 4 - Ops can use all commands including /stop , /save-all , /save-on , /save-off , and /reload

(from: https://minecraft.gamepedia.com/Server.properties).

So in short: I feel the auth method should be definable depending on need, andnot be locked down on only one (if we wish to expand on the local OS user management), and it should support mixed method user management, depending on user level. (not all server admins wish to beminecraft users, not all users need access to the server).

1 Like
5

In terms of authentication and permissions I believe a good example to take a look at would be webmin, and as for it being per-system I think it depends on the person really, the web ui would handle the majority of everything so it really wouldn’t need to be a per user per system thing I don’t think unless you plan to implement per-user linux/filesystem access; you could require a single user account to be created and available on the backend systems with account details entered in the front end (for example, mc:mc could be a single account and password to all the backend systems, and the front end handles what is possible vs what is not possible). Additional accounts could be created manually by the user or maybe via the web ui, mainly for use on the front end system, optionally for use on the back ends. Accounts managed with mineos could be synced somehow between all systems (optional) if needed for some reason. Normally I have better more thought out ideas but life so sorry they aren’t as clear as they normally would be.

I think overall a webmin like design might be best, since with the way that I look at it, things are kind of getting to that point where I believe if you were to add or implement a few of the relevant features/functions available in webmin that it could (or should) make things a bit easier to think and plan out/about. There are a ton of things I see and have used before previously in webmin that would have been nice to have within mineos itself, but I understand the complications between different distributions…well it’ll get there to that point anyways I think.

Alright, so MineOS could have different server groups which correspond with unix groups, if you’re not part of that unix group you don’t have access to that server, pretty similar to the way things are now. This could tie in to user authentication if there’s a MineOS server group that corresponds with a unix user group, on the front end. This will eliminate the need for any backend user accounts apart from the one that would be used for communications between the front and back end(s).

6

Congratulations I’m looking forward to it!

Please allow for two factor authentication. Minecraft servers tend to be targeted by disgruntled players.

I would suggest toml instead of using yaml, can get complex especially with white spaces and verbose. Preferably it would be abstracted away by the web UI anyway.

Fine-grained control is important for anything for hosting multiple and complex minecraft servers with multiple server administrators.

MySQL would be crucial for performance with medium to large instances for hosting infrastructure. Although it be nice if you could dump the tables and restore them with the a backup procedure.

Could you clarify .5?

Consider UI function alternatives such as keyboard shortcut for disability accessibility.

1 Like
7

I’ll address all of you guys in-line:

What @JayMontana36 is closer to what I’ve already engineered, in terms of Linux users.

As of right now, mineos-ruby does not require root. This is by design, because requiring root had always been one of the biggest glaring issues that I feel I introduced to security. Many servers use root, but then de-escalate permissions to a non-root account and rely on things like PAM in order to do auth. Unfortunately, either my a) coding aptitude or b) coding enthusiasm waned too greatly to implement this like how, say, Apache or other webservers do.

HQ: currently runs as non-privileged user. Depends on an S3 object store like AWS S3 (but users won’t likely use this). Instead I offer Minio, a self-hosted S3 object store that is AWS-S3 compatible and is awesome.

Worker: currently runs as non-privileged user. Does not require to match the non-privileged user of the HQ. Right now, all server instances are created and owned by the user running this worker.

The system I’m modelling this after is virtualization software, such as VMWare server and Xen. On these setups, no matter who owns the VM on the VM hosts, all the instances are run by the same user on the host itself, and users do not ever touch the backend systems (the worker nodes). This means that users will not SCP/SSH to the worker nodes–this is a big deviation from normal mineos-node. Archives, imports, profiles–all of these come from the object store which the workers have access to.

It’s a good time as ever to emphasize that while this is the next iteration of MineOS, there are sooooooo many use cases where MineOS-ruby will not be recommended over MineOS-node. I know that all users want the best and newest (the least buggy and the most featured), but so much changes in this release that I imagine that it won’t even be considered for half the installations that exist nowadays because of the amount of infrastructure changes.

Since this is a configuration that is aimed toward server administrators hosting, at the minimum, >1 minecraft instance, the current design idea for multiple users is … multiple worker processes. Whether that’s one worker process on one node and a second worker on a second node, or whether its two workers on the same single node, is up to the resources of the machine.

Of course, multiple servers from one user is the current case I’ve been developing for, and requires only a single worker instance.

In the latter case, having two lightweight workers opened by two separate users means that we get the benefit of userland separation (perms on filesystem as well as process separation). Realistically–though this hasn’t been implemented–it could also be possible to have every minecraft instance have their own worker process (this would then be modeled by Android, which does create a new throwaway user for ever process). I don’t expect to go this direction because I’m trying to stay as distro-agnostic as possible, and tapping into users anywhere but the HQ seems to defy this aim.

This is something I wasn’t aware of, having not played the game in nearly a decade lol. It is important to know, though, since I wouldn’t want to overlap these. I’m wondering, though, are these ops levels supported in most/all of server softwares? If not (or if it’s not universally used), it might still be marginally useful to implement on the mineos end. After all, people don’t need to, in any capacity, use fine-grained control if we take it for granted that people just can trust the admins who have webui access.

I’ll put further thought into this, thanks for the info.

Yep, you pretty much nailed it.

Leaning away from this for the above-stated reasons. posix was a demon-child of a problem with npm and the fewer places where I can rely on bridges to distro-specific authentication, the better. I’m hoping this means that the auth will work on literally every distro that supports ruby, right out of the box. And keeping auth off the workers also means that workers can be installed on any distro, even mix and matching servers on FreeBSD, Ubuntu, and Arch…without any changes.

This will definitely be a late-addition, if I’m able to at all. It’s definitely an awesome idea, so I hope that somebody has already done the work for me in a ruby gem and implementation is only a short amount of work. It definitely would put an extra bit of polish and shine on a new product. Of course, right now, I don’t even have a webui, so you can bet such an addition will have to wait.

Never heard of toml before, but I am wary to not only have to learn a new MUL, but also to expect all users to learn it as well. YAML, at least is pretty widely used. I do like that toml doesn’t depend on whitespace as heavily and it seems quite elegant, but it’s still to be determined whether or not I’d want to hinge the permission model on a language I myself am not very good at.

You’re absolutely right. For the audience that mineos-ruby has, it almost seems like a given that a MySQL instance will exist already for Minecraft, so why not re-use it for auth!

Ughghghghg, but then that also means I have to implement SQL… and man, I hate doing SQL lol. A bigger deal would be “what level of operation could be expected in the webui if MySQL is misbehaving?” After all, it’s only going to be used for auth, and it feels like a huge burden to install and administer (from my “creating test servers during development” standpoint).

It’s also another place where I can imagine a huge amount of support requests on discourse/emails.

Considering that the auth tables would be like 10 rows, tops, MySQL as a requirement for that seems overkill, even if it’s able to re-use an existing instance (again, from my dev standpoint). Flatfiles might take me ten minutes to write parsing code for, but SQL might take a few hours and not be particularly stronger at what it’s doing.

Mostly I’m just considering the layout of the webui. In the current webui, it just lists all the servers. In the upcoming webui, should it do the same, with no regard to what host it’s placed? In other words, “is what host a mc instance is on actually actionable knowledge?” Will designing the webui to share “server X is on host Y and server P is on host Q” be something that matters in the day-to-day upkeep?

Obviously the owner of the server will care where it’s created, but that’s what I’m wondering if the importance ends there. Moving mc instances from one server to another isn’t something that should be constantly done, anyway, and moving mc instances will be very doable through already-existing functionality of archive/import.

I suck too much at UI building to think I can implement this well. Hopefully when that time comes, the webui will be a place where I can get community help.

But that does bring up a great tangent:

Because of the way the HQ is designed, all of mineos-ruby can be managed via REST API calls. This means that the humdrum webui I create can easily be replaced by ANYbody’s webui that implements these calls.

Also it means that everything in the webui is possible with curl on the command line.

There’s probably more I could comment on, all, but I’m gonna try writing up a few more commits now.

1 Like
8

I’m not sure if you are still following this thread, but a few ideas I have would be 1) an in webui update for the commits, nix updates and distros releases. 2) Any thoughts on adding clustering to other hardware for scalability?
Sorry if this was already mentioned in other posts.

9

It’s possible. I’m currently trying to engineer a solution around spawning worker processes on the worker nodes through a second background process. Unfortunately, this second process would need to be run by root (but would fortunately be a tiny daemon), though its existence would also be multi-purpose (good for multiple users).

So I know it’s technically possible, though I’m weighing whether or not it would raise program complexity within reason.

Can you clarify what you hope to achieve through clustering?

Minecraft itself has no means to benefit from clustering (say, in the way like a mysql server does), and since Minecraft is a single process that runs only on a single node, I’m not sure to what end MineOS would benefit from clustering either.

But if you’re referring to the notion of just being able to have MineOS manage multiple hosts on multiple servers and have its infrastructure run on multiple nodes, then that is certainly doable (and is already implemented).

Just let me know what use case (just from the big picture standpoint) you have in mind.

10

What I was thinking was being able to add more hardware to the environment. Having multi user accounts running multiple mc:servers can impact the overall performance of a single computer(server). By using clusters, the OS can perform load balancing.

11

Unfortunately, I’m still not following what you’re asking about.

Load balancing for what aspect of the Minecraft stack? Because while Minecraft load balancers exist, they’re typically just there to route players from one Minecraft instance to a separate one, which can already be done now. MineOS doesn’t restrict use of such utilities, just sometimes it isn’t integrating them.

If you’re referring to just having different server instances on separate machines, this is already implemented.

12

Maybe thinking like having one host server using the hardware of other physical computers to increase performance if the Administrators (people) decide to increase the their setup as a whole.

This diagram may explain what I mean (this is not my image mind you)
https://goo.gl/images/EF34wV

13

Keep in mind what role MineOS plays in the hosting stack–it’s a front-end to insulate users from the command line. So the next question is, is what you’re describing (in the picture) something that is possible with Minecraft currently?

14

This isn’t a function of Minecraft itself, but is available for ‘nix machine as something that can be configured. Where the webui comes in would be to integrate resources of the slave nodes.

Might need to table this as another project as this would require linux packages install, configured and compiled.

15

Clustering itself is something that Linux can do, yes, but more importantly, is whether the app itself supports that kind of functionality.

I’m not sure Minecraft vanilla or even custom server softwares are currently at a place where it can support–to any degree–clustering and distribution of resources for a single Minecraft instance.

16

I see C++, does that mean bedrock will now function in conjunction with MineOS? (Actually show up as a selectable server type)