Root user and /etc/rc.initial



  • 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.)



  • 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.



  • 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.



  • 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!



  • 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.)


Log in to reply