Re: mutilog via fifo

richard lucassen <[email protected]> Mon, 4 Aug 2008 00:20:00 +0200
Newsgroups gmane.comp.djb.syslog
Organization XAQ Systems
Message-ID <[email protected]>
On Mon, 04 Aug 2008 07:11:13 +0930
Daryl Tester <[email protected]> wrote:

> > It is an permission problem:
> > 
> > open("/dev/stderr", O_RDWR|O_APPEND|O_CREAT, 0666) = -1 EACCES
> > (Permission denied)
> 
> (O_CREAT? O_RDWR? shudder).
> 
> Richard, what platform is this?  This result that you're seeing infers
> that /dev/stderr isn't changing ownership after the process issues a
> setuid().  I've just tried this on a Linux 2.6.24 box, and /dev/stderr
> (which is symlink'd to /proc/self/fd/2) does change ownership after
> the setuid(), and hence who can access it, which is what I would
> expect.

What happens (AFAIUI) is that elhttp is trying to write to the fd that
had been opened by root. Normally it changes ownership of course (Debian
running a vanilla kernel)

And elhttp runs under its own uid, which is set by tcpserver (-U
option). I think elhttp is writing to its "own" stderr, and that's
a different pipe. But don't shoot me, I'm not a fd guru ;-)

> > So publicfile is started as root, and thus has access to
> > /dev/stderr, and after that changes uid/gid. Right or wrong?
> 
> As Paul has pointed out, publicfile (and programs written the
> "elegant" way) use the inherited file descriptor (2 = standard error).
>  This opening of /dev/stderr is the not normal method.

I agree, normally there is the name of the logfile. Have a look at it,
it's a very small proxy for embedded systems:

http://dl.xaq.nl/linux/elhttp/

It was written for stand-alone use and later for running under inetd.
The author never kept in mind that there are some idiots around who use
tcpserver, multilog and svscan ;-)

R.

-- 
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht                                        |
| Public key and email address:                                    |
| http://www.lucassen.org/mail-pubkey.html                         |
+------------------------------------------------------------------+