Re: Proposal for write(1) addition

[christos%astron.com@localhost (Christos Zoulas)]

In article <201109180419.AAA06102%Sparkle.Rodents-Montreal.ORG@localhost>,
Mouse  <mouse%Rodents-Montreal.ORG@localhost> wrote:
>> pututxline() runs a setuid program to update utmp if needed, so it is
>> transparent to the user.
>
>Well, mostly transparent.  But it could just as easily - and
>approximately as transparently - send a packet to a daemon instead;
>there's nothing sacred about utmp_update.

Simplicity, plus the benefit of having getppid() handy.

>One potential major advantage and one potential minor advantage.
>
>The major one is compatability.  Code that Just Works all the way from
>when ptys were first invented up to now.  Avoiding the "another system,
>another idiosyncratic `you must do *this* dance to make ptys work'"
>#ifdef (or equivalent) hell - worse, in this case, because in addition
>to code authors having to deal with the different API, the end system's
>admin has to get something right too.

We had the ifdef hell before POSIX ptys were invented. Now at least it
is standardized. Plus all the security holes for requiring setuid so
you can chown (or suffer the consequences of using a publicly writable
pty; no thanks.)

>Is that worth being mired in the past, shackled to accidents of the
>first implementation?  Sometimes it is; sometimes it isn't - this is
>why I called it a _potential_ advantage.  The only real problem I see
>here is that NetBSD is (apprently) not letting admins make that call
>for themselves.  (Providing ptyfs for cases where it's a right answer
>is good.  Requiring its use for ptys to work, not so much.)
>

>It's true that NetBSD used to provide no more choice.  But to switch
>and _still_ provide no choice is kind of the worst of both worlds: you
>lose compatability and you don't gain the flexibility of multiple
>options.

Unfortunately NetBSD lets you use BSD ptys too still.

>> [...] and the exposure of the control node.
>
>This is the minor one.
>
>I'm not convinced losing the ability to expose the master-side device
>is a good thing.  (Certainly losing the requirement to expose it is;
>it's losing the ability to that I'm not so sure about.)  I have no
>specific use case; it just feels like preventing stupid things at the
>price of preventing clever things.

Heh, you still get it, just not the node.


christos