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