[Cadaver]

Several months ago I had to enable Root in an attempt to fix some volume mounting problem (which, turns out, was fixed by other means). I thought I had disable root, but today I realized I was able to SSH in to my G5 as Root. Not good.

I can't find an option in NetInfo Manager to disable Root (just one to enable). OK... how do I disable Root?

And before anyone tells me I shouldn't have enabled Root in the first place, you are correct. I shouldn't have. But at the time, I was desperate to fix the damn thing.

Edit: let me elaborate... In NetInfo Manager, under Security, it never gives me the option to "disable root user," just "enable root user." This is even after I authenticate. This would lead one to believe root is not enabled. However, it actually is still enabled because I can SSH in as root (after supplying root's password) from a terminal session. Something's not right, I don't think.

[utidjian]

This is a "known problem". I have been bitten by the same or similar bug. From what I have read one possible scenario is if you enabled root in Jaguar (10.2.x) and upgraded to Panther (10.3.x) and THEN tried to disable root... the system would give you the impression that the root account is disabled but it really is not. This is indicated by the fact that you can still ssh in (even log in on console) as root.

How to fix...

There is a discussion here: http://forums.macrumors.com/archive/index.php/t-75243
and here:
http://discussions.info.apple.com/we...RB.3@.68989d0d
and here:
http://discussions.info.apple.com/we...RB.3@.68973863
and so on...

Basically it boils down to some inconsistencies with how netinfo deals with the root account and, presumably, the differences between Jaguar and Panther.

No one would ever notice this problem unless they have enabled root at some point... even just for a looksee. The simple act of temporarily enabling root either out of curiosity or perceived neccessity should not "break" the security of the system.

The main security advantage of disabling the root account is that it makes it far more difficult for an attacker to exploit some weakness in the system and drop to a root shell... if such a weakness ever exists.

At some point enabling the root account was neccessary in order for Carbon Copy Cloner to work correctly. I don't know if that is still true (or ever really was).

In Mac OS X Server the root account is enabled by default. Why? I don't know.

[Cadaver]

Thanks for the info!
I'll try the suggestions in those linked threads today when I get home.

In the meantime, I've disabled Remote Login on the computer and disabled port 22 forwarding in my router as precautions. My root password probably wasn't (isn't) the most secure - since I thought it would be easily disabled once I was done with it. And my port 22 (SSH) has been scanned recently... some jerko from an IP address traced back to Russia has been trying different usernames and root passwords.

[sambeau]

For the future you can do all root things in the terminal by typing

Code:
sudo su -

or

Code:
sudo bash

you can then do root stuff (including opening dirs/stuff with 'open').

[Cadaver]

Originally posted by sambeau:
For the future you can do all root things in the terminal by typing...

Oh, I know. But what you can't do is operate the GUI at the root level via SUDO from the terminal.

I (thought I) needed access to root at the GUI level to attempt to mount volumes to the Finder that would not under a regular admin account. They mounted to /volumes without problem and I could access them via the Terminal (from any account) but were not accessable via the Finder. I wanted to see if root's desktop had the same issue.
(It did, by the way.)

Turns out this was an issue with 256MB video cards (eventually fixed with the 10.3.5 update). There were a couple threads about this floating around here on MacNN and on the Apple support boards.

But, alas, my root user got stuck in an enabled state.... Hopefully the links above will correct the situation.

[Person Man]

Originally posted by utidjian:
At some point enabling the root account was neccessary in order for Carbon Copy Cloner to work correctly. I don't know if that is still true (or ever really was).

I've never had to enable the root account (or even log in as root) in order to use Carbon Copy Cloner.

[Cadaver]

Originally posted by Cadaver:
Thanks for the info!
I'll try the suggestions in those linked threads today when I get home.

In the meantime, I've disabled Remote Login on the computer and disabled port 22 forwarding in my router as precautions. My root password probably wasn't (isn't) the most secure - since I thought it would be easily disabled once I was done with it. And my port 22 (SSH) has been scanned recently... some jerko from an IP address traced back to Russia has been trying different usernames and root passwords.

Update... (for those who care)

Removing the "authentication_authority" and "generateduid" entries as suggested resulted in a hang at the login window upon reboot. A second reboot was successful, sort of... it took a long time for the login window to appear, and after logging in (as my regular admin account) any attempt at launching an app would hang the system (infinite spinning beach ball). Drat! It was worth a try.

Anyway, a simple archive and restore was successful at fixing both the root user problem and the hang at login. Took less than 15 minutes thanks to a 10,000 rpm WD Raptor system drive.

No data, apps or preference settings lost

Lets see a Windows reinstall that can claim that.

Special thanks to Utidjian

[Angus_D]

Originally posted by Cadaver:
Oh, I know. But what you can't do is operate the GUI at the root level via SUDO from the terminal.

That's because you ABSOLUTELY, UNEQUIVOCALLY SHOULD NOT EVER DO THAT. If you do, STOP IT IMMEDIATELY and repair permissions.

There isn't really anything you can do from the GUI that you can't do from the CLI, either. As of 10.3, the Finder will let you authenticate to operate on the filesystem if you absolutely have to, on a per-file/directory basis, I think.