Poll: Preferred authentication method for new webui

  • utilize usernames and groups from the underlying system, e.g., ‘will’, ‘user’ [current system]
  • implement Mojang IDs “Yggdrasil” for granular permissions, single superuser admin account.
  • usernames only, not tied to the underlying system or Mojang IDs

Descriptions

1) The current web-ui uses the usernames and groups existing in the Linux distribution and membership to the group gives 100% access to the server via the web-ui.

Pros:

  • leverages matured security system from the kernel/filesystem
  • same username has webui and shell access (+SFTP)

Cons:

  • sysadmins often have no idea how to manage usernames/passwords that they don’t use anywhere else
  • all permissions given, from backup/delete/archive/start/stop. no granularity

2) Yggrasil permissions use the username/passwords already used to log into Minecraft

Pros:

  • will be very easy to remember, manage
  • can granularize permission granting, e.g., giving a given username permissions to do X, but not Y.
  • users will be able to log into the web-ui as read-only

Cons:

  • All admins required to have either a Mojang ID or be trusted with the web-ui superuser, e.g., ‘admin’
  • Shell/SFTP not available except to the web-ui superuser

3) Create usernames that have no ties to anything other than the web-ui.

Pros:

  • easy to create users and grant permissions

Cons:

  • another set of username/passwords that must be remembered
  • shell/ftp not available except to the web-ui superuser

I welcome your vote and your ideas for any other implementations, tweaks to make this more usable! Please also try to specify a few things about your community:

  • size of community
  • desired number of people who would be trusted with web-ui (ideally)
  • are you for or against regular usage of the command line/SFTP in your daily administration?

So people without Mojang account (like me) will not be able to use MineOS as non-trusted users? Any Mojang ID owner will be able to see dashboard (ram, hdd, cpu load, etc)?

What about for 4th option: use system names, but implement a database for additional granularity/permissions.
Pros:

  • 1 password for all ssh/sftp/MineOS
  • Granularity

Cons:

  • Okay, another password along Mojang’s (Users can use the same, though)
  • Hard to implement?
  • No (possible) integration with server (chat from MineOS as MC user, etc.)

Way to implement without database: use system groups for certain permissions (e.g.: start_stop, maintenance, change_settings, use_console, read_only, etc ), and add user to groups to use perms.
Pros:

  • No need for database
  • Can be used for system purposes (e.g. r/w access to backups for maintenance members)
    Cons:
  • Less granularity for hard-coded groups
  • Implementation for group membership check (already done in current version?)
  • System groups’ overuse in non-dedicated setups (?)
  • Size of community (which specifically?) Servers users (30-40 active) Servers staff users (about 15)
  • Trusted Web-UI users 2-3
  • Current MineOS cannot cover everything, so CLI/SFTP usage is common now, but it will be useful to have this in Web-UI. Though I mostly use Midnight Commander for shell, and I understand it cannot be used through Web-UI anyways.
1 Like

I don’t think any Mojang account could log in only those to whom permissions have been granted by a super user.

Well, as I could see that in the new methods, the FTP is a problem, as I am not really familiar with your codes, I might have a solution that will interest you.

I am guessing you are going to use SQL (as it might be a simple and good solution) if you are using the method 3. If that is the case, I strongly suggest you to check out ProFTPD, as it could use SQL to verify the users, set a homedir for each of those user. Although it requires a sql module which in my option it isn’t too hard to do. It also feature lot more, such as a apache-like configuration. I try that with my own little linux server and it works…eh fine, I guess? Not really test too much with that.

Back to which method I prefer, will be method 3. As it is more freely than any other method above. For those 2 methods they are heavily rely on something that a sysadmin have so little control, so that translates to a lot of trouble for sysadmin when comes to troubleshooting, and also management.

Resources:
http://proftpd.org/docs/howto/Authentication.html
*/Please look under Authentication categories, which contains links to sql module setup and usage howtos.

FTP is a much inferior, much less dependable protocol alternative to SFTP. SFTP would allow all the same functionality as FTP, but be far more hardened, not require additional config (creating homedirs, something adduser already does to perfection) and an additional open port. In addition, it provides no shell access (which is a good thing to offer!) and is an additional dependency not already on the server (SSH/SFTP is on all servers already). All in all, SFTP will be much preferred, although that is really nice that ProFTPD would work with SQL…never knew that!

I originally thought about using SQL for implementing permissions, etc. though I find myself gradually leaning away from it for one reason. Simultaneously implementing kernel-based permissions (i.e., linux users) and made-up users really complicates the security/authentication model of MineOS. As the sole contributor of code, I judge it won’t be a lot of fun to tack that atop what I still have ahead of me in nodejs/webui integration and the new iteration of ‘profiles’ (hopefully, something everybody will understand more easily!).

Right now I’m tossing some ideas around in my head that work with the normal system users (full access) and Mojang IDs for limited access, though I haven’t decided yet. One reason I’m really pro-mojang IDs is that I can much more easily facilitate permission sharing (on a server-to-community level) because an admin will already know their handles and it can be implemented in the web-ui rather than in CLI (or learning how to have nodejs interact with SQL interact with ProFTPD).

It’s all still up in the air! I’m doing some heavy thinking still.

If you wanted we could make a page or function to create a new linux user and also delete add groups etc.
:edit:
I have looked into authenticating against with linux users. I am not the most knowledgeable but it’s not looking promising. How were you planning on doing it? Utilising PAM?
I’d like to try my hand at creating a single page application and this would be the first step.

Auth via https://github.com/bahamas10/node-etc-passwd

The size of my community is about 10ish reg players with many more that come and go. I would have 3 people with console access including me. I use SFTP a lot to upload mods and world files since I run a huge modpack (200+ mods).
Based on all this I think I would prefer option number two since I am the only one who makes major changes hence needing SFTP. Most other people only need to restart (or stop) the server when a mod(s) starts acting up. In my case everyone already has a Mojang account so it makes that easy. However I would love for there to be a guest mode (that can be disabled) that lets people log in as a guest meaning that have read access only to the places where you let them. The guest account would be an account that has one username (guest perhaps) and one password (configurable perhaps guest as default). The guest mode I would (myself other people may choose to set up differently) allow people to see ram usage!

May be this must be in feature request topic, but it’s more user-management related - it would be nice to have some Web-ui options configured per user (like language, theme…).

I prefer the current implementation. As very few people should have access to server controls. A separate page that’s read-only for community to have access regarding server status, performance, and other useful statistics. You could also include on that page comments denoting reasons for server rollbacks or a request for server backup.

As a side thought it would be great if users could report on that status page “grieving”
As simple as logging a timestamp so the server admin can rollback the server to the appropriate backup. Otherwise it’s a much more in depth process to track down in the logs. Since we don’t have a log parser that allows us the narrow down events or events generated from plug-ins.