[Fwd: Finger problem on Solaris with 2.2.4 (PR#24659)]

[Andrew Bartlett]

David Lee wrote:
> 

> This can be classed as a "known problem" and that it does, indeed, relate
> to the utmp support as enabled by "--with-utmp".  (It was I who wrote
> Samba's original "utmp" code, using Solaris as a starting point, although
> this particular issue only emerged much later.)
> 
> There is also a possible workaround we (Samba folk) could do, which can
> actually also increase Samba's overall functionality.
> 
> Problem analysis:
> 
> One could argue that it's a bug in Solaris:  that Solaris shouldn't care
> about the (lack of ) reality of the "/dev/smb/n".
> 
> On the other hand, one could argue that we (Samba) shouldn't be using a
> non-existent "/dev/smb/n" as though it were real.  (But this fake-device
> is a vital component of "utmp" support, and, given that we have to use it,
> we ought to ensure that if fits the overall "/dev/..." model.)
> 
> But of course, such mutual finger pointing ("it's their fault") won't get
> us very far towards resolving the problem.
> 
> Towards a solution (and bonus Samba functionality!):

There is another solution:

simple touch /dev/smbd/{1 - 3000} with empty files or symlinks to
/dev/null.

But I know you want more than this :-)

> I have proposed an idea which not only solves this problem but also
> increases the functionality of Samba.  My idea is for smbd, or something
> affiliated, simply to be able to maintain the "/dev/smb/n" tree as
> connections come and go.  That solved the problem (I checked by adjusting
> a copy of smbd source code accordingly).
> 
> And it also would add further value to Samba.  Because once it exists, it
> can then be used as a real device for sys.admins (and users?) to be able
> to use the existing "write(1)" and "wall" commands to send WinPopup
> messages to smb client users.
> 
> (Our environment is a university campus with sometimes 1000 simultaneous
> connections, and occasionally we need to be able to get "alerts" out to
> current users about imminent events: naturally we try to keep these rare,
> but sometimes they are nececssary!)

Certainly it could be useful in that the system will also broadcast some
of this stuff - like shutdown messages.  Then again, some of the other
system broadcasts might not be desirable...

> Now, if Andrew Bartlett is reading this...!  Andrew, bear with me...!

I'll try :-)

> And if Gerald (Jerry) Garter is reading: you, too, may recognise this.
> 
> So my trial implementation was:
> 1. "smbd" to create/delete "/dev/smb/n" as a "named pipe";
> 
> 2. "smbd" then to include this in its "select()";
> 
> 3. anything appearing on "/dev/smb/n" to be sent to the client PC as a
>    WinPopup, using code very similar (and potentially common) to
>    "smbclient -M".
> 
> As a proof of concept it solved the "who" problem, and added this extra
> wall/write functionality.
> 
> Technical detail:
> 
> Andrew Bartlett and I had a couple of discussions during the last year or
> so about this issue, with some initial technical disagreement, but
> reaching a resolution.
> 
> My original idea, and "proof of concept" demonstration was simply to allow
> "smbd" to create/remove "/dev/smb/n" entities.  Conceptually very simple,
> and the implementation inside "smbd" is almost trivial.   (The WinPopup
> thing was a little harder, but still reasonably straightforward.)
> 
> Andrew B. (and, I understand, Tridge) are unhappy about smbd itself
> diddling about in "/dev/", even if (as I proposed) that it be a "smb.conf"
> parameter to allow (default disallow) such diddling.  OK, fair enough.

If we create smb.conf options, people use them.  Then we get the blame. 
And they don't read the manpage either - see recent discussion on
'delete user script' and people loosing thier 'root' account...

> We agreed on a compromise that a PAM module could be used to do the
> "/dev/smb/n" diddling.  Although that doesn't help non-PAM systems
> (Solaris, fortuately, is PAM-based).
> 
> Summary, including proposal:
> 
> 1. A known problem.
> 
> 2. Fix is simple if in smbd, and still relatively simple if in PAM
>    (although latter doesn't help non-PAM systems).

Or also simple if we add a 'sesion exec'.  I never got time to put such
a patch into practice, but if sombody else wants to put it togeahter...

> 3. If "fix" (whether smbd or PAM) uses a named-pipe (or similar) we can
>    also gain write/wall added functionality.

Which could indeed be quite useful.  But outside smbd :-)

> I hope that the Samba Team can agree the principle.  If so, then I would
> willingly and gladly contribute my "work in progress", and, further,
> adjust it to their recommended CVS version (which?  2_2?  3?  HEAD?) for
> such developments.

The principal is fine 'hooks for such things should be provided' :-)

Andrew Bartlett

-- 
Andrew Bartlett                                 abartlet at pcug.org.au
Manager, Authentication Subsystems, Samba Team  abartlet at samba.org
Student Network Administrator, Hawker College   abartlet at hawkerc.net
http://samba.org     http://build.samba.org     http://hawkerc.net