Pro version - root login now only shows one out of 100+ users

SYSTEM INFORMATION
OS type and version Ubuntu 20.04
Webmin version REQUIRED
Virtualmin version 6.17.gpl-3
Related packages SUGGESTED

Hi guys,

A client phoned to say they can’t login to Virtualmin. We checked and double checked, and indeed, the clear text password and username didn’t work.

We also noticed an SSL issue, and requested new SSL which worked according to the output.

However, now, when we log in as our root user, we can’t see any other users, except the one we troubleshooted a few minutes ago.

Essentially the control panel now only works for one user only, as both primary and backup root users we have only displays this one user.

@staff I really need your help.

Hi,

Perhaps you have a limit set for number of domains to display in System Settings ⇾ Virtualmin Virtual Servers ⇾ Configuration: User interface settings?

A client phoned to say they can’t login to Virtualmin. We checked and double checked, and indeed, the clear text password and username didn’t work.

Please double check that Webmin Login feature is enabled on Edit Virtual Server page.

Also, can you provide a screenshot of how it looks?

This happens if you create a domain owned by root or assigned ownership of an existing domain to the root user, which basically changes the permissions to those of a domain owner. It doesn’t make sense to do this (because root “owns” all domains), and Virtualmin shouldn’t allow you to do it, so it’s a bug.

Confirm that’s what happened by looking in /etc/webmin/webmin.acl. If the root: line is very short and only has a few modules listed (like a half-dozen or so, probably), then this is the explanation.

If that is what happened, you’ll need to re-grant root all permissions by editing the /etc/webmin/webmin.acl file and changing the root: line to something like this:

root: acl adsl-client ajaxterm apache at backup-config bacula-backup bandwidth bind8 change-user cluster-copy cluster-cron cluster-passwd cluster-shell cluster-software cluster-useradmin cluster-usermin cluster-webmin cpan cron custom dfsadmin dhcpd dovecot exim exports fail2ban fdisk fetchmail filemin filter firewall firewall6 firewalld fsdump grub heartbeat htaccess-htpasswd idmapd inetd init inittab ipfilter ipfw ipsec iscsi-client iscsi-server iscsi-target iscsi-tgtd jabber krb5 ldap-client ldap-server ldap-useradmin logrotate lpadmin lvm mailboxes mailcap man mon mount mysql net nis openslp package-updates pam pap passwd phpini postfix postgresql ppp-client pptp-client pptp-server proc procmail proftpd qmailadmin quota raid samba sarg sendmail servers shell shorewall shorewall6 smart-status smf software spam squid sshd status stunnel syslog-ng syslog system-status tcpwrappers telnet time tunnel updown useradmin usermin vgetty webalizer webmin webmincron webminlog wuftpd xinetd virtual-server virtualmin-awstats virtualmin-htpasswd virtualmin-sqlite virtualmin-slavedns virtualmin-registrar virtualmin-init virtualmin-git ruby-gems php-pear jailkit authentic-theme virtualmin-nginx virtualmin-nginx-ssl virtualmin-dav virtualmin-disable virtualmin-google-analytics virtualmin-iframe virtualmin-mailrelay virtualmin-messageoftheday virtualmin-notes virtualmin-oracle virtualmin-password-recovery virtualmin-powerdns virtualmin-signup virtualmin-styles-openwebdesign virtualmin-styles-oswd virtualmin-svn virtualmin-vsftpd webmin-jailkit virtualmin-support virtualmin-mailman

Then restart the webmin service. You’re mostly done. I think some modules will still have some restrictions, which you may need to remove in the Webmin Users module, but since your root user is back to mostly being root, it should be possible from within Webmin.

I really would like to know how you convinced Virtualmin to do this, if that’s what happened. There used to be several ways to make it happen (some subtle, some required a user doing something that doesn’t make sense), but I thought they were fixed years ago.

I can’t do either of this, because the root user now has non-root permissions. No more Systems Settings nor Edit Virtual Server permissions. I can’t even see those menus anymore.

@Joe I think you might be onto something.

BUT, root has all those permissions you specified.

HOWEVER, what is strange:

  1. The non-root account (sitename1.acl) didn’t have a listing in webmin.acl
  2. There are a bunch of files names sitename2.acl, sitename3.acl.

root.acl has these settings:

uedit_mode=5
negative=1
feedback=0
rpc=0
gedit_mode=2
readonly=
root=/home/sitename1
gedit=sitename1
fileunix=sitename1
uedit=sitename1

there is no sitename1.acl

I really need urgent help. Our control panel has no more administrative rights.

I really would like to know how you convinced Virtualmin to do this…

I have webminlog.csv export which appears to have a fairly detailed log of what went down, but it’s as I described. I can email that to you?

Please help guys, as soon as a client phoned we are screwed as we can’t do anything anymore.

@Ilia here is a screenshot

I found an exact post with a similar problem and I’m working through that now:

https://archive.virtualmin.com/node/11802

EDIT: That was the solution. It appears at some stage today when the user sitename1 was accessed, a file called “root.acl”, present in /etc/webmin and another 16 subdirectories, inherited the permissions of sitename1 rendering the panel into a non-administrative state where only sitename1 is visible and not much else.

I had to delete all 17 of those files called ‘root.acl’.

I only recall trying to reset the password for sitename1, and requesting an SSL certificate.

Thanks @Joe and @Ilia without something to try I would have been screwed. Back in business, yah!

To showcase the amazingness of Virtualmin:

image

Can you tell us what you were doing when this happened? I’m guessing that maybe your browser filled in root and the root password on the Edit Virtual Server page, maybe? (Though that shouldn’t work…so, maybe some other page? But, I still suspect browser auto-fill somewhere.)

Can you tell us what you were doing when this happened?

I’m looking at the logs now.

  1. Client call to say they want to log in.
  2. Normally I log in as a SUDO user, myname. Today I logged in as another little used SUDO user, aname.
  3. I navigate to Edit Virtual Server, Configurable Settings, to retrieve username and clear text password.
  4. I open Incognito Window to try and log in with said username and password. It doesn’t work.

Things go haywire after that. So perhaps your theory is correct, that somewhere a session cookie is stored and when I did incognito although it looked like I logged in as the user, I was actually in as root or something.

That’s about all I can say for now, but thanks so much, when you mentioned these ACL files I googled “root.acl” and almost immediately found that legacy post. So all good.

I’m guessing that maybe your browser filled in root and the root password on the Edit Virtual Server page, maybe?

This probably confirms the browser auto-fill hypothesis, since it would mean the domain owner user would have gotten set to the root password in the process, probably.

Still unsure what form or page could trigger this, though, since as far as I knew until this thread, we’d fixed it so you couldn’t do something like this, even if you tried (since it doesn’t make sense to do).

If the file that Joe mentioned earlier (i.e. /etc/webmin/webmin.acl) looks okay, then you’d be able to navigate to Webmin ⇾ Webmin Users: Edit Webmin User / Available Webmin modules / Virtualmin Virtual Servers and check on ACLs set there:

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.