smbwall

[David Lee]

On Thu, 31 Jan 2002, Andrew Bartlett wrote:

> Scott Gifford wrote:
> > 
> > David Lee <t.d.lee at durham.ac.uk> writes:
> > 
> > [...]
> > 
> > > > As someone pointed out, pseudo terminals come pretty much in
> > > > 2 flavors: BSD & System V.
> > >
> > > I suspect we may be using loose terminology.  I think the phrase "pseudo
> > > terminal" was intended to represent a model of doing things, not
> > > necessarily as an real implementation detail.
> > 
> > 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... ]

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

We might be getting somewhere here.  I know that Andrew is very keen on
keeping things consistent (e.g. his tidying up of authentication things,
of which I've heard, but not yet investigated, but sounds excellent!).

When I wrote Samba's "utmp" code, the utmp interfaces on UNIX machines
required me to have something (anything) as a tty-like entity.  I invented
a purely fictitious "/dev/smb/<n>" nomenclature.  This is a figment of
"smbd's" imagination (no real existence on the system).  Anything else
could have been used, although the "/dev/" prefix seems to be close to
essential.

The important point is that the current "/dev/smb/<n>" name is simply a
fictitious convenience, for an imaginary tty-like entity. 

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

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.

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

In principle, I think we're there, aren't we?  

-- 

:  David Lee                                I.T. Service          :
:  Systems Programmer                       Computer Centre       :
:                                           University of Durham  :
:  http://www.dur.ac.uk/t.d.lee/            South Road            :
:                                           Durham                :
:  Phone: +44 191 374 2882                  U.K.                  :