headers
Peter Hickman | 25 Apr 2012 12:20
Gravatar

Getting a process to run as root

I have an application that scans log files that is written in Ruby. It
is installed as the user log_watcher but needs to be run as root so
that it can have the rights to read the various log files that it
needs. Essentially the service/log_watcher/run file comes down to
"sudo ruby log_watcher.rb", the log_watcher user has passwordless sudo
rights.

We have runit / supervise installed but when we try and start the
application it complains about supervise/ok or supervise/lock being
unavailable which means that the process is not being restarted after
a reboot.

How do I get to run the process as root from the log_watcher user.
I've tried various things I've seen in the wiki and got back from
googling but nothing seems to work. Or perhaps there is another way
around this?
Permalink | Reply | 9 comments |
headers
Wayne Marshall | 25 Apr 2012 15:07

Re: Getting a process to run as root

On Wed, 25 Apr 2012 11:20:41 +0100
Peter Hickman <peterhickman386 <at> googlemail.com> wrote:

> I have an application that scans log files that is written in
> Ruby. It is installed as the user log_watcher but needs to be
> run as root so that it can have the rights to read the various
> log files that it needs. Essentially the
> service/log_watcher/run file comes down to "sudo ruby
> log_watcher.rb", the log_watcher user has passwordless sudo
> rights.
> 
> We have runit / supervise installed but when we try and start
> the application it complains about supervise/ok or
> supervise/lock being unavailable which means that the process
> is not being restarted after a reboot.
> 
> How do I get to run the process as root from the log_watcher
> user. I've tried various things I've seen in the wiki and got
> back from googling but nothing seems to work. Or perhaps there
> is another way around this?
> 

Normally a supervision environment runs with root permission by
default.  This means that all your supervised services will
*start out* with root privilege.

Many supervision packages include utilities that may be used to
shape the permissions of service processes.  In practice, these
utilities are used as a means to *drop* privilege, so that
your service will then run without root permission.
(Continue reading)

Permalink | Reply | 8 comments |
headers
Peter Hickman | 26 Apr 2012 17:11
Gravatar

Re: Getting a process to run as root

Thanks for your help. I've added the missing groups to the user and
when I run the script from the command line it works fine (sh
./service/log_watcher/run).

However when I use sv start ./service/log_watcher/ the permissions
have disappeared and the files can no longer be read.

I have updated the /etc/sv/runsvdir-log_watcher/run to include the
necessary groups to the chpst -u option but it does not seem to help
(I have also tried the -U option to no avail)

Any idea where I should be looking?
Permalink | Reply | 7 comments |
headers
harish badrinath | 26 Apr 2012 17:15
Picon

What is the process group hack

Hello,

I Could not figure out what "process group hack" is supposed to be
utilized for ??
Is it used to supervise daemons that stubbornly fork into the background.
Could anyone please explain with an example, i would be really helpful.
I have to the best of my abilities RTFM'ed and searched the internet.

Thank you,
Harish
Permalink | Reply | 4 comments |
headers
Mike Buland | 26 Apr 2012 17:52
Picon

Re: What is the process group hack

Hello,

At least one good example is getty processes.  There are a number of
systems (including newer linux kernels, but this may be optional) that
will not allow a process that is not the parent of it's own process
group to take an unclaimed terminal device as it's controlling
terminal.  getty programs don't generally make their own process
groups, and neither does runit for it's services, so the program group
hack is necessary to run a getty program on many systems.

Although I believe that you're right, it was intended in daemontools
as a way to try to supervise a process that wanted to daemonize, I've
never had experience using it in that capacity myself.

--Mike Buland

On Thu, Apr 26, 2012 at 9:15 AM, harish badrinath
<harishbadrinath <at> gmail.com> wrote:
> Hello,
>
> I Could not figure out what "process group hack" is supposed to be
> utilized for ??
> Is it used to supervise daemons that stubbornly fork into the background.
> Could anyone please explain with an example, i would be really helpful.
> I have to the best of my abilities RTFM'ed and searched the internet.
>
> Thank you,
> Harish
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wayne Marshall | 26 Apr 2012 20:27

Re: What is the process group hack

On Thu, 26 Apr 2012 20:45:28 +0530
harish badrinath <harishbadrinath <at> gmail.com> wrote:

> Hello,
> 
> I Could not figure out what "process group hack" is supposed
> to be utilized for ??
> Is it used to supervise daemons that stubbornly fork into the
> background. Could anyone please explain with an example, i
> would be really helpful. I have to the best of my abilities
> RTFM'ed and searched the internet.
> 
> Thank you,
> Harish
> 

This question refers to specific utilities in the daemontools
suite by Daniel Bernstein.

pgrphack is simply a wrapper around the setsid(2) system call.
It runs a process in a new session and process group.  See the
man page for setsid(2) for more information.  See also the
source file pgrphack.c in the daemontools distribution.

fghack is djb's "anti-backgrounding" utility.  It invokes
strangeness and mysteries to inhibit a process from forking into
the background.  Dunno about examples.  Normally it is not used
because: 1) nowadays most programs that daemonize will be
decently written and offer an option to run in the foreground;
or -- if such option is not provided -- 2) it is usually a
(Continue reading)

Permalink | Reply | 2 comments |
headers
Wayne Marshall | 26 Apr 2012 20:49

Re: Getting a process to run as root

On Thu, 26 Apr 2012 16:11:55 +0100
Peter Hickman <peterhickman386 <at> googlemail.com> wrote:

> Thanks for your help. I've added the missing groups to the
> user and when I run the script from the command line it works
> fine (sh ./service/log_watcher/run).
>

When you run the script from the command line, you should be
able to invoke it directly, and not as an argument to the sh
command interpreter.  That is, this should work:

./service/log_watcher/run

If not, then you have a problem:

* Does your run script begin with "#!/bin/sh" ?

* Is your run script set executable with chmod +x ?

> However when I use sv start ./service/log_watcher/ the
> permissions have disappeared and the files can no longer be
> read.
> 
> I have updated the /etc/sv/runsvdir-log_watcher/run to include
> the necessary groups to the chpst -u option but it does not
> seem to help (I have also tried the -U option to no avail)
> 
> Any idea where I should be looking?
>
(Continue reading)

Permalink | Reply | 6 comments |
headers
Charlie Brady | 26 Apr 2012 21:02
Picon
Picon

Re: What is the process group hack


On Thu, 26 Apr 2012, Wayne Marshall wrote:

> fghack is djb's "anti-backgrounding" utility.  It invokes
> strangeness and mysteries to inhibit a process from forking into
> the background.

No, it doesn't change anything about the way the process operates. It just 
starts the process in a child process, and attempts to stay around until 
that process exits. 

See the description here:

http://cr.yp.to/daemontools/faq/create.html

fghack creates a pipe from the daemon and reads data until the pipe is 
closed. Normally all the daemon's descendants will inherit the open pipe 
from the daemon, so the pipe will not be closed until they all exit.

However, fghack will exit early if the daemon goes out of its way to close 
extra descriptors. A few of these daemons leave descriptor 0 open, even 
though they do not use descriptor 0; so

     #!/bin/sh
     exec fghack baddaemon <&-

might work.
Permalink | Reply | 0 comments |
headers
Laurent Bercot | 27 Apr 2012 03:20
Favicon

Re: What is the process group hack

 Just to clarify:

 There are two different tools that should not be confused.

 * The "process group hack" tool, prgphack. It's not a real hack,
it's just a call to setsid(2).

 * The "foreground hack", fghack. This one is a real unadulterated
100% ugly hack. It's used to allow self-backgrounding processes to
be still managed by a supervisor.

 Documentation - sparse, but accurate - about those tools can be found
on the daemontools web site:
 http://cr.yp.to/daemontools/fghack.html
 http://cr.yp.to/daemontools/pgrphack.html

> It should be mentioned that daemontools itself should be
> considered deprecated by several alternatives currently
> available and under active maintenance.  For example, runit,
> daemontools-encore, and perp.

 And s6. Please. :P

--

-- 
 Laurent
Permalink | Reply | 0 comments |
headers
Peter Hickman | 27 Apr 2012 11:18
Gravatar

Re: Getting a process to run as root

When I run it just as ./service/log_watcher/run it runs fine

Here is the /etc/sv/runsvdir-log_watcher/run file

#!/bin/sh

RUNIT_USER=log_watcher:root:adm

exec 2>&1
exec chpst -u$RUNIT_USER runsvdir /home/log_watcher/service

I've tried a variety of combinations and values for the -u and -U
settings to no avail

The program runs but when it attempts to access the log files it no
longer has permission to do so (just like it was before I added the
missing groups to the log_watcher user).
Permalink | Reply | 5 comments |

Gmane