Re: 'syslogd -u' and pidfile creation

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Fri, 8 Nov 2024 12:02:38 -0500 (EST)
    From:        Mouse <mouse%Rodents-Montreal.ORG@localhost>
    Message-ID:  <202411081702.MAA21137%Stone.Rodents-Montreal.ORG@localhost>

  | What is the intended use case for -u?

My guess would be so that the syslogd process isn't running as root,
and so can do less harm if some bug is uncovered in the processing
messages it receives from a remote host (or even the current one).

  | My own reaction is that if you're using -u, it's not appropriate to
  | write the usual system-wide PID file in its usual place,

But it also would not be appropriate to open the sockets (binding to
the ports) or the output log files in its usual place either - so if
you imagine that -u is so some user can have a private syslogd running
for their own messages, I don't believe that is its intent.

As for:

jschauma%netmeister.org@localhost said:
  | Does that seem reasonable? 

The patch looks OK to me, but wrt:


jschauma%netmeister.org@localhost said:
  | One thing to note is that upon termination, the pidfile will remain
  | (albeit truncated), because the unprivileged user does not have write
  | permissions on /var/run.

I agree this is mostly harmless (though annoying) - but leads me to
ponder whether or not we should have a directory permission setting
which would allow anyone to remove their own files from a directory,
but not create any (assuming they don't also have write permission,
which has to be the case or they can remove any files, unless
one of the setuid bits is set, like in /tmp).

Even though it is not at all meaningful in any naming sense, perhaps
we could reuse the sticky bit on directories (which was once used for
what is now the setuid bit) to allow for this operation, precisely for
directories like this, where a priv'd process creates a file (or files)
in some directory, chowns them to some user, then runs as that user until
exit.   There's no policy reason to retain the files - the priv'd process
could just fork() and have its parent wait on the child, and then delete
everything that needs deleting, so a mechanism already exists - but is
fairly heavyweight for such a simple requirement.

An alternative might be to add extra meaning to the setuid/gid bits
which currently are useful only if the relevant write permission bit
is available, and in that case are restrictive rather than permissive,
so that if write perm for the user isn't available, they'd mean that
unlinking a suitably owned file would still be possible when write
permission otherwise forbids it (adding permissions in that case).
I think I'd prefer to use the t (sticky) bit, as that overloading of
meanings for the user & group setuid bits might be rather confusing.

And (just to reply in advance, just in case) to the "shouldn't this
be an extended attribute type thing?" question - yes, it probably should,
but so should all permissions.  But EAs only work on filesystes formatted
to permit them (none of mine do, for example) which makes that a far less
attractive solution to be something which ought to be able to work anywhere.

So, any general opinions on this, were it to get implemented ?

kre