ripcd is running as root.

Just for yucks, I created a script "bs.pl" that is run from "bs.sh" that is run from a Rivendell macro cart via "RN /home/scott/rml/bs.sh!". It uses '$username = getpwuid($<)' to get its effective user ID and then writes that into the log.

To my surprise, bs.pl is running as 'scott'!

That means this must be an OS problem not a Rivendell problem. 'scott' clearly doesn't always have the group permissions of 'dialout', even though it does when I'm logged in as 'scott' and running scripts from the command line.


Rob

--
Я там, где ребята толковые,
Я там, где плакаты "Вперёд",
Где песни рабочие новые
Страна трудовая поёт.

On Tue, 9 Oct 2018, David Klann wrote:

On 10/9/18 8:54 AM, Rob Landry wrote:

...

rd.conf is set to run Rivendell as user 'scott'. I do this because it is
easier to debug external scripts if Rivendell is running as the same
user I log in as.

However, what I've just discovered is that the Bruins scripts are
failing because they don't have permissions to access the serial port --
even though user 'scott' is in the dialout group and does have such
permissions.


Hey Rob,

From what I know /etc/rd.conf doesn't actually specify the user ID under
which to run the daemons. On a CentOS installation the service daemons
(caed, ripcd, rdcatchd) run as user root. And in fact /usr/bin/caed is
normally configured to run SUID (set-user-id) by doing chmod u+s
/usr/bin/caed to make sure it runs as that user ('root' on CentOS).

That means that at least part of Rivendell must be running as a user
other than 'scott'. 'chmod o+rw /dev/ttyS0' cures the problem.

The obvious question is: what user is it running as? Since the scripts
were working from the command line, 'scott' clearly had permissions to
access the serial port.


Here's a Linux ps(1) alias I use to help understand the user ID's
process are running as (watch the text wrap, it's all on one line):

alias pss='/bin/ps -N --pid 2 --ppid 2 --format
pid,ppid,tty,user,group,wchan=-----------WCHAN-------------,%mem,%cpu,lstart,args
--sort start_time --forest'


I vaguely recall having encountered this problem before. This is RD 2.18
running on Debian 8. There's no SELinux installed, so it can't be
anything like that.

For now, I'm adding 'chmod o+rw /dev/ttyS0' to my startup script, as
that seems to be an effective workaround; but I'd love to understand why
the problem crpped up in the first place.

Long story short: I'd check ownership and permissions of /usr/bin/ripcd,
and the process owner for the running ripcd process.

Hope this helps a little!

 ~David Klann

_______________________________________________
Rivendell-dev mailing list
[email protected]
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Reply via email to