Re: Proposal: Add option to add dates to write(1)

[Matthew Mondor <mm_lists%pulsar-zone.net@localhost>]

This isn't to debate about this particular change, I understand after
Julian's explanation that the current design requires the sender to
emit the timestamp, unless there were tty or design changes.

But this thread made me wonder if there are people who think that
there's a need for an eventual write(1) replacement that would be more
secure, and could handle this particular need gracefully.  The first
question being: is this worth it? :)

The write(1) utility would either connect to a local socket or send
datagram messages to such local socket, which would be handled by a
small system daemon (and write(1) would no longer need setgid).  The
daemon would have access to write to ttys (running as an unprivileged
user with access to the tty group), and would talk a very simple
protocol, getting uid/tty to send to, as well as the line/message.

This daemon could verify the connecting (or message sending) client-user
credentials (using ancilary data), verify if the target allows write
messages, and write messages to the corresponding tty including the
user ID/name and time information (we could also add the PID if
wanted).  The sender would not be able to spoof identity or timestamp,
and no changes to the tty code would be needed.  The daemon also could
log via syslog authpriv unauthorized attempts or errors.

If datagrams are used, the daemon design would be very simple, simply
handling one message at a time arriving on a single descriptor.  I no
longer remember if only connected stream sockets receive client
credentials, but if so, I could introduce or adapt an old patch (which
had been proposed under kern/39108 and the thread
http://mail-index.netbsd.org/tech-kern/2008/07/05/msg001969.html).
Even if datagrams were used, the write(1) interface could remain as-is,
with line/paragraps sent individually and immediately while still
waiting for EOF.  However, there probably would be a datagram size
limit, limiting the possible length of a line.

Streams also could be used, but with slightly increased complexity (no
need for threads or forking, though).

If some people want this, I could add this to my TODO, and eventually
implement it (client, daemon-server, daemon man page, as necessary
kernel credential passing extension).  Of course, I don't object if
someone else wants to implement it, and I could offer assistance/review
if desired...
-- 
Matt