gmane.comp.sysutils.supervision.general

Re: Getting a process to run as root

Laurent Bercot — 2012-04-28T01:17:45

 http://xkcd.com/763/

 I absolutely *do not want to know* how "chef", whatever that is, installs
and administers its computers.

Re: Getting a process to run as root

Charlie Brady — 2012-04-27T14:56:02

On Fri, 27 Apr 2012, Peter Hickman wrote:


And indeed it is. You are dropping priveleges from runsvdir, and then need 
to add them later via sudo. If you leave runsvdir running as root, and 
drop priveleges in each service run script, then you will have a simpler 
setup. You will also be avoiding sudo, which is a large complex program 
which does not have a perfect security record.

Re: Getting a process to run as root

Peter Hickman — 2012-04-27T14:42:21

There we go solved, in my case at least. I kept the
/etc/sv/runsvdir-log_watcher/run file as it was but changed the
/home/log_watcher/service/log_watcher/run file to this:

#!/bin/bash

set -e

EXEC="sudo -u log_watcher ruby log_watcher.rb known_logs.yml"

# Run the script.
cd /home/log_watcher/log_watcher/current
export RAILS_ENV=production
exec $EXEC

The significant change was adding the "sudo -u log_watcher" to the
EXEC string. To be honest it seems horribly convoluted but it seems to
work just fine.

Again thanks for the help.

Re: Getting a process to run as root

Peter Hickman — 2012-04-27T13:44:00

To be honest this is just the way someone else set it up for our other
projects (we install all this via chef) and it is working fine for
everything else we run. It's just that this is the first time we have
needed to elevate privilege.

Ah well just have to keep on hacking at it.

Thanks for all your help it has definitely got things moving.

Re: Getting a process to run as root

Wayne Marshall — 2012-04-27T11:13:29

On Fri, 27 Apr 2012 10:18:52 +0100
Peter Hickman <peterhickman386< at >googlemail.com> wrote:
 

I see evidence of more than a few problems here.  For example,
why would you be using runsvdir in a service definition?

Anyway, it would appear that your basic runit installation and
setup may be a little confused.  Hopefully some runit users here
will be able to give you some good suggestions.

BTW, if you should ever decide to give perp a try, you may be
pleased to find you don't have to mess around with any symlink
indirection to install your service.  Then I could suggest an
rc.main runscript for your "log_watcher" service that looks
something like this:

#!/bin/sh
# /etc/perp/log_watcher/rc.main

exec 2>&1

TARGET=${1}
SVNAME=${2}

RUNUID="log_watcher"
GROUPS="log_watcher:adm"

start() {
  echo "starting ${SVNAME}..."
  exec runuid -S ${GROUPS} ${RUNUID} /path/to/log_watcher
}

reset() {
  echo "resetting ${SVNAME}..."
  exit 0
}

eval ${TARGET} "$< at >"

### EOF

Wayne
http://b0llix.net/perp/

Re: Getting a process to run as root

Peter Hickman — 2012-04-27T09:18:52

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

Re: What is the process group hack

Laurent Bercot — 2012-04-27T01:20:25

 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



 And s6. Please. :P

Re: What is the process group hack

Charlie Brady — 2012-04-26T19:02:26

On Thu, 26 Apr 2012, Wayne Marshall wrote:


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.

Re: Getting a process to run as root

Wayne Marshall — 2012-04-26T18:49:20

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


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 ?


To say anything more about this, we would really need to see the
complete source of your run script.

Wayne

Re: What is the process group hack

Wayne Marshall — 2012-04-26T18:27:53

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


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
simple matter to delete a few lines of the offensive source code
to cut out the daemonizing behavior.

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.  I believe most of these tools now
run each service in its own session and process group as a
matter of course, something that daemontools does not do, unless
you yourself explicitly run each service under the pgrphack
utility.

Why does this matter?  If the entire supervision tree runs under
a single process group, that entire process tree can be crashed
under certain conditions in some cases on some platforms.  Which
is a bad thing.

Internally segregating each service into its own process group is
more reliable, and generally eliminates any need for something
like pgrphack within the service definitions themselves.

Wayne
http://b0llix.net/perp/

Re: What is the process group hack

Mike Buland — 2012-04-26T15:52:12

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:

What is the process group hack

harish badrinath — 2012-04-26T15:15:28

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

Re: Getting a process to run as root

Peter Hickman — 2012-04-26T15:11:55

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?

Re: Getting a process to run as root

Wayne Marshall — 2012-04-25T13:07:46

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


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.

The point here is that your scenario is rather uncommon, because
evidently you are using sudo in a runscript to *escalate*
privilege.  That is usually not done.

My suggestion is that you try to think through your service
again, to clarify what you are trying to accomplish.

Based on the information you have provided, it would seem
feasible to run the "log_watcher" service without root
privilege, as long as you can assign it all the group read
permissions it needs in order to access the various log files it
is scanning.

See for example the runuid(8) utility in the latest perp
distribution:

http://b0llix.net/perp/site.cgi?page=runuid.8

The -S option for this utility allows you to run a process as an
unprivileged user, and with any number of supplementary group
permissions.

Best regards,

Wayne

Getting a process to run as root

Peter Hickman — 2012-04-25T10:20:41

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?

Re: problem with mailing list and multipart/mime?

Laurent Bercot — 2012-03-10T16:34:57

 I'm sorry I haven't taken the time to look into this. Debugging other
people's code is what I do all day at work, and it's a painful, boring
and infuriating task - and I just can't get myself to do it again when
at home. ;)

 However, the skarnet.org server is going to migrate to another platform
soon (say, in about two or three months), and I'll use this opportunity
to upgrade the mailing-list management software to a somewhat less
ancient version. I hope the bug will be fixed in the upgraded version.

[announce] perp-2.05: persistent process supervision

Wayne Marshall — 2012-01-11T12:52:43

Announcing the latest release of perp, a persistent process
supervisor:

 http://b0llix.net/perp/distfiles/perp-2.05.tar.gz


What's New:

 * a couple of bugfixes for bigfuxes!

 * enhanced runuid(8) utility!

 * bigger release number!


About:

perp is a service supervisor similar in purpose to the venerable
daemontools package, providing a modern update with many
advantages:

 * easy configuration: in place service activation and no
   symlinks!

 * everthing administered in /etc/perp

 * fully FHS compatible

 * scanner/supervisor/controller runs as a single process

 * all context switching for multiple supervisor processes is
   eliminated

 * service reset capability

 * pretty good troff -man documentation

 * colorized(!) service lister, readable timestamps...

 * no slashpackage, no slashcommand, no slashdoc...


More:

 http://b0llix.net/perp/


Best regards,

Wayne

Re: problem with mailing list and multipart/mime?

Jameson Graef Rollins — 2011-10-22T19:49:23

Well, ironically, that message I just sent to the list shows that the
problem has nothing to do with multipart/signed messages, since that
message wasn't signed.  The message was just multipart/mixed.  And again
the MIME structure was destroyed by the list when a single content
boundary line ("--==-=-=") was removed from the message.  I hope that
helps clear things up.

jamie.

Re: problem with mailing list and multipart/mime?

Jameson Graef Rollins — 2011-10-22T19:43:31

Re: problem with mailing list and multipart/mime?

Jameson Graef Rollins — 2011-10-22T19:16:24

Re: problem with mailing list and multipart/mime?

Laurent Bercot — 2011-10-22T11:47:47

 The mailing-list software *modifies* the message - namely, it adds a few
headers (such as List-Unsubscribe) and removes other headers (such as
Return-Path - for obvious reasons). So, it's normal that you cannot
verify the signature of a message after it goes through the list.

 The adding and removal of headers should be perfectly safe and I don't
think there's a bug in there. On the other hand, there *might* be a
problem with the handling of MIME types, because it's something
complex. The set of MIME types that are forbidden (i.e. if such a MIME
type is encountered in a multipart message, the corresponding part of
the message will be deleted) is the default set for the version of
ezmlm-idx I am using. It includes text/html; it does not include
text/plain, of course; and it does not include application/pgp-signature.

 Since messages are modified when going through the list, it makes no
sense to sign them, so I might as well add application/pgp-signature
to the list of removed MIME parts, and end this bit of confusion.

 If you think you have exhibited a real bug, such as a text/plain part
of a MIME message being removed, please send proof to me: a message
sent 1. to the list and 2. directly to me (using the address in the
"From:" header of this message, and replying to the confirmation
request), so I can compare the two and use it to investigate. But
ezmlm-idx has worked flawlessly for years, and the MIME filter has
being treating us pretty well, so I don't think there's a bug involved -
at most, a misconfiguration on my part is possible.

 Anyway I'll be away for the week-end, so we'll see this next Monday.