Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Root user and /etc/rc.initial

    Scheduled Pinned Locked Moved 2.0-RC Snapshot Feedback and Problems - RETIRED
    5 Posts 2 Posters 4.9k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • S
      smitelli
      last edited by

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

      1 Reply Last reply Reply Quote 0
      • E
        eri--
        last edited by

        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.

        1 Reply Last reply Reply Quote 0
        • S
          smitelli
          last edited by

          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.

          1 Reply Last reply Reply Quote 0
          • E
            eri--
            last edited by

            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!

            1 Reply Last reply Reply Quote 0
            • S
              smitelli
              last edited by

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

              1 Reply Last reply Reply Quote 0
              • First post
                Last post
              Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.