smbwall

[Scott Gifford]

David Lee <t.d.lee at durham.ac.uk> 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
about.

> > > 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
important.

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.

----ScottG.