This one is really at the hairy edge of race conditions.
   IF an LPRng server process needs to send a signal to another process

     AND the LPRng server is currently euid daemon (or lp, or whatever)

     AND at the time the signal is sent the remote process is NOT
        euid daemon because it did a seteuid(root) to do some operation
        that required root privileges (grrr... hatums RFC1179!),
        such as doing a bind() or setsockopts() system call

     THEN the signal will not get delivered to the process

There are several places where this has a effect:
  1. lpc status operation
      - false indication 'subserver' process is not active
     lpc kill/abort operation
      - the 'subserver' process will not get kill
         BUT the server process will...
        (minor fixup for this problem)
  2. lpq status operation
      - false indication 'subserver' process is not active
  3. lprm operation -
      if active job is removed the server may not get
      killed.

The 1 and 3 can be 'robustified' a bit,  but it is
difficult to make it guaranteed to work without
doing a 'seteuid(root)'.  I hate to do this,  as the
few places where I do this are VERY carefully controlled.

While I cannot think of a way that this could be exploited,
the thought of having a process EUID root sending a signal
to another process VERY dangerous...

So I will live with the race condition for now.

Note:
  It took Heroic Efforts (i.e. - sleep(20) all over the place)
to set this up to test.  The window where this can happen
is VERY narrow - effectively when the 'subserver' process for
a queue is doing a socket(), bind(), or setsockopt() call.
These should proceed with alacrity, and should not block in
the kernel waiting for some other event.

Patrick

-----------------------------------------------------------------------------
YOU MUST BE A LIST MEMBER IN ORDER TO POST TO THE LPRNG MAILING LIST
The address you post from MUST be your subscription address

If you need help, send email to [EMAIL PROTECTED] (or lprng-requests
or lprng-digest-requests) with the word 'help' in the body.  For the impatient,
to subscribe to a list with name LIST,  send mail to [EMAIL PROTECTED]
with:                           | example:
subscribe LIST <mailaddr>       |  subscribe lprng-digest [EMAIL PROTECTED]
unsubscribe LIST <mailaddr>     |  unsubscribe lprng [EMAIL PROTECTED]

If you have major problems,  send email to [EMAIL PROTECTED] with the word
LPRNGLIST in the SUBJECT line.
-----------------------------------------------------------------------------

Reply via email to