Root user and /etc/rc.initial

smitelli

I'm a big fan of pfSense, been using 1.2.3 in an office environment for about 11 months now.

After upgrading to 2.0-RC1, I notice that a script I wrote to backup my bandwidthd data stopped working. In trying to figure out why, I came across the following oddity. Not sure if it's a bug or a feature.

In /etc/inc/auth.inc, we do this:


        /* root user special handling */
        if ($user_uid == 0) {
                $cmd = "/usr/sbin/pw usermod -q -n root -s /bin/sh -H 0";
                if($debug)
                        log_error("Running: {$cmd}");
                $fd = popen($cmd, "w");
                fwrite($fd, $user['password']);
                pclose($fd);
                $user_group = "wheel";
                $user_home = "/root";
                $user_shell = "/etc/rc.initial";
        }

… and then a few lines down ...


        /* add or mod pw db */
        $cmd = "/usr/sbin/pw {$user_op} -q -u {$user_uid} -n {$user_name}".
                        " -g {$user_group} -s {$user_shell} -d {$user_home}".
                        " -c ".escapeshellarg($user['descr'])." -H 0 2>&1";

If I'm reading this right, this sets the shell for the 'root' user to /etc/rc.initial, every time the system reboots. (I think?) Now, my question is, why is this being done here? I understand that rc.initial provides the "pick a number" menu when 'root' logs in via SSH, but is also breaks SCP/SFTP.

If I run 'chpass', I can reset root's shell to /bin/sh or /bin/tcsh or something, and SCP/SFTP will start working. But after the next reboot, it's back to /etc/rc.initial and back to breaking SFTP.

Why not set the shell to /bin/sh on boot, then rely on .shrc or .profile or whatever to display the menu if appropriate?

(Full disclosure, I'm not a FreeBSD guy. Like, at all.)

eri--

You are misreading it because root will always have /bin/sh shell while other users will have rc.initial, mostly.
The code below you reference sets /etc/rc.initial for users with uid = 0 but not root since root is not a user in the GUI.

smitelli

Here's the thing though, I do have a 'root' user in the webGUI. Its uid is 0, and it has <scope>system</scope> in config.xml. I'm guessing it's the old webGUI user from the 1.2.3 install I copied the config from. (I named that user 'root', for reasons that I now can't even remember.) See:

 <user><name>root</name>

	<scope>system</scope>
	<password>{REMOVED}</password>
	<uid>0</uid>
	<priv>user-shell-access</priv>
	<priv>user-copy-files</priv>
	<authorizedkeys>{REMOVED}</authorizedkeys></user>

In my instance, the $user_shell = "/etc/rc.initial"; line definitely is setting root's shell to rc.inital every time the system reboots; if I comment the line out and reboot, the shell instead gets set to tcsh.

Perhaps this is an instance of my own dumb configuration choices, but I feel like there should either be some kind of warning to not pick 'root' as a webGUI username if it will mess things up, or maybe some more graceful way of sanitizing weird configs during the upgrade process.

eri--

Well its your choice to do so and not sure we would want to stop you here.
Though you can add a TODO entry in redmine.pfsense.org to discuss this and not get lost.
IMO it should stay as it is!

smitelli

Well, I think what I'll do tonight (if I can schedule the downtime) is revert to the "factory" RC1 without importing my config, then play around with the user manager to get a feel for how it interacts with SSH out of the box. When I import my config, I'll try to hand-edit the current 'root' username to anything else except 'root'/'admin' and see if it behaves any differently.

I wasn't suggesting we outright block users from being able to do these things, but maybe there should be a simple notice somewhere explaining that they might have unintended or non-obvious repercussions. (Kind of like how pfSense now warns not to use .local as a LAN domain name – you still can if you really want to.)