I’ve collided with some issues and bugs regarding user management. These aren’t severe but are annoying, and the changes required to remedy them are minor.
Issue One: UID Assigned to Admin User on First Installation
When Rockstor is first installed, the Web UI starts on a page that gives the Rockstor appliance a name and specifies the name and password for the Admin user. This user is given the UID 1000 automatically. This UID causes problems when Linux workstations connect to this appliance via NFS. The solution: give the initial Admin user a different UID like 5000.
Detailed Explanation
Modern Linux distros typically give the user a UID of 1000 by default. So on my workstation, user “Walt” has UID of 1000. User ID mapping through NFS is by UID not by name string, so to assign storage on the Rockstor appliance to user “Walt” I’d have to create a user named “Walt” and give it a UID of 1000. But 1000 is already taken. The workaround is to create a new Admin user account with a different UID like 5000, then log out and log back in as that new user, then delete the original Admin user account. Then create a user account named “Walt” and give it UID 1000.
Issue Two: No Way to Delete a Non-Admin User
The Web UI does not have any ability to edit, modify or delete non-Admin users. The solution: at the very least, provide a trash-can icon like the Admin users have, so users can be deleted (and later re-created with modifications if needed).
Detailed Explanation
I reset the installation by deleting the /opt/rockstor/.initrock file. This didn’t remove the Admin user accounts but demoted them to “other” users without Admin capability. So when doing initial setup of the Admin user, I was not able to use the usual admin user names, “admin” and “administrator” previously defined but had to give some other name. Once in the web UI there isn’t any way to remove those user names, promote them to Admin users or otherwise edit UIDs and GIDs. Other than to drop out of Rockstor and log in as root.
Issue Three: Samba Admin Users
This one is arguably not a bug, but it caused issues and required hours of debug so I’ll describe it here in the hope that a better way can be found. The root cause of the problem was that if a Samba export designates an Admin User, that user accesses the filesystem as root, and every file it creates is given ownership of root:root. The optimum solution is debatable but I’d argue for deleting the ability to designate an admin user at all.
Detailed Explanation
My initial usage of Rockstor was in a Windows-only environment. Same username and password across all computers. So when I set up Samba I casually threw in my username as the Admin user for each Samba export. I didn’t realize initially, that each share when first created, is given default ownership of root:root (that information is rather hidden on the Shares page, along with the means to edit it). I assumed that the files I was creating from Windows computers had my username as owner. I can read or write all files, so no problem, right?
The problems surfaced when I started migrating to Linux recently. Samba works like crap on Linux, so I set up NFS. But that quickly ran into sharing issues. I did a bunch of experiments and eventually tracked down the issue that Samba was converting my user account to root when accessing the file system. The entire file system was owned by root, not by the user account that I’d set up.
Giving a user unrestricted root access is dangerous. I suppose that in some corporate environments there is a need for a user with root access to snoop into every user’s account, so there’s an argument in favor of having the facility to define a Samba Admin user. But there are limited things that such a user could do. I don’t know of any way that such a user could chown files or release a lock on a file for a user for example. So it doesn’t replace superuser login through a terminal. Since any file that the Samba Admin user writes would have root ownership, this admin account is unsuitable for use for regular file storage.
I’d just get rid of it entirely. But if not, at least put Admin users of Samba (and NFS?) onto a page of their own specifically for designating Admin users, along with enough text to caution that Admin user accounts should only be used for administrative tasks and not for routine file storage. And I’d have it refer the user to a documentation page that explains things in detail.
