Scott Gifford sgifford at
Thu Jan 31 13:20:06 GMT 2002

David Lee <t.d.lee at> writes:

> On Thu, 31 Jan 2002, Andrew Bartlett wrote:
> > Scott Gifford wrote:


> > > I believe that I'm the one that started talking about pseudo
> > > terminals, and I actually did intend it as an implementation detail.
> [ sorry for any mis-representation there... ]

No, it's good you said what you thought I meant; otherwise we'd just
all go on with our own assumptions and never know what we were talking

> > > They are widely available, mostly portable, easily understood, and
> > > well-tested.
> > > 
> > > You can pretty much copy a couple dozen lines out of Stevens' Advanced
> > > Programming in the UNIX Environment and have a quite portable
> > > implementation in an hour or so.
> > 
> > We already have most of this, becouse the 'unix password sync' occurs
> > over a tty.
> Thanks.
> Could you briefly point us to a source file in Samba?  (With a version
> number, because I seem to recall that some of the password handling has
> been substantially changing in recent months/weeks.)

Look at findpty at chgpasswd.c:45 in the today's CVS.


> So it seems entirely reasonable to migrate.  No longer use a fictitious
> "/dev/smb/<n>", but rather a real "/dev/pts/<n>" (or whatever is the
> natural name for that particular host OS).
> Then smbd can grab (or at least allocate) that 'real' pseudo-tty, and use
> its name in the utmp/connection stuff. 
> Then, if "smb.conf" directs, it can also open it and listen on it for real
> "wall", "write", etc., and translate these into WinPopup messages.
> There we are.  Mission accomplished, absolutely cleanly.  No run-time code
> anywhere doing "/dev/blah/"-creation.  The real UNIX utilities "simply
> work".

I think this is absolutely the solution.

> As an incidental benefit, we also now have a subroutine interface within
> smbd, so smbd internals (e.g. vfs modules) can message the user.
> What does it need?
> 1. Connection/utmp code to use names consistent with ttys on the OS,
>    and whose name is allocated "live" in co-operation with the OS.

And I think most of this is in findpty().

> 2. If smb.conf option directs to enable wall/write-like support then
>    smbd opens that same tty and adds it to the select list for reading.
> 3. If input arrives on that tty, it is sent as a WinPopup, using code
>    from libsmb and friends.  (Detail: that code needs some adjustment for
>    this use, but this can be retro-fitted cleanly and transparently
>    into the libsmb library.)

It's a little trickier than that, since there aren't clear message
delimiters, but it should still be do-able.  I wrote a little
proof-of-concept program that read from a TTY, then packaged up a
message when it hadn't received anything new for 5 seconds.  That
should work well enough for what we need; it did the write thing for
"echo message |write samba" and "wall message", which is what's

Unfortunately, when I tried to port it to use Samba's more portable
findpty and utmp code, I got into Dependency Hell and couldn't get it
to build.  Somebody with more knowledge of Samba would probably be
able to throw something together relatively quickly.


More information about the samba-technical mailing list