Different service status using pfSsh.php after Upgrade to 2.8.1
-
We started upgrading our pfSenses to 2.8.1 (from 2.7.2). After the upgrade we experienced a problem when using pfSsh.php by a dedicated user to check the status of a specific service.
When I'm logged in as root and I call
/usr/local/sbin/pfSsh.php playback svc status unboundfrom CLI, I get:
Service unbound is running.When I'm logged in as user "monitoring" and I call
/usr/local/sbin/pfSsh.php playback svc status unboundfrom CLI, I get:
Service unbound is stopped.Weird behavior. In 2.7.2 that worked flawlessly. I've no clue, what's wrong...
-
Same behavior here. Presumably it's the result of some permissions hardending. A user not privileged to modify an elevated service should not be able to determine the status of said service.
-
In 2.7.2 the user "monitoring" had only one effective privilege: "User - System: Shell account access".
Now in 2.8 I also assigned "WebCfg - Status: Services" to that user to check whether it's a permission thing.When I log into the Web UI the only page I'm able to access is the Services status page - what I expected. So far so good. I'm able to check and to start/stop services from GUI.
But the pfSsh.php still says...
Service unbound is stopped.Any other ideas?
-
I did some debugging this morning. The problem is in this file:
/etc/inc/util.incThere is a function called is_process_running. Back in 2.7.2 this function used "/bin/pgrep -anx processname" to determine whether a process is running. Since commit 1d9aa24 "pkill -0 -x processname" is used to do that.
Logged in as user "monitoring" you can see the different behavior:
> /bin/pgrep -anx unbound 10790 > /bin/pkill -0 -x unbound pkill: signalling pid 10790: Operation not permittedI have no idea whether it is intended or a bug
-
Hmm, likely an unintended side effect of the switch. I'd expect you can use sudo there to allow it if you need to.
-
@stephenw10 correct. That's the workaround I'm using right now.
