SYSKEY, TNG freeze, 2.0.x->TNG merge and other thoughts

[Nicolas Williams]

On Wed, Feb 09, 2000 at 06:54:35AM +1100, Luke Kenneth Casson Leighton wrote:
> >    I'm now for it as Luke's LDAP/NIS/other name services argument is a
> >    winning one. The /etc/shadow approach should still be supported and
> >    used where no such cleartext protocols are in use.
> 
> the SYSKEY2 thing also means that private/smbpasswd can be made
> world-readable.  sounds weird, neh?  WAIT - hear me out, before shooting
> mouths and telling me it's a stupid idea.  i didn't say make the SYSKEY2
> key world-reabalb, that _is_ a stupid idea.

No, what you're suggesting is silly. The SAM RPC daemon should always
run as root, so there will be no need for those become_root()/
unbecome_root() calls.

Trust me: the SAM RPC daemon should always run as root.

> however, the _only_ reason that we have to do this, in ALL samba
> user-enumeration code in samrd:

[... psuedo-code with become_root()/unbecome_root() calls ...]

> is because private/smbpasswd is root-only readable.  yes, there appears to
> only be a password in it, but there's not, it identifes which unix
> accoutns are also samba accounts.

The SAM RPC daemon should always run as root.

[...]

> >    The question now should be one of scheduling/prioritizing. SYSKEY is
> >    not needed urgently to allow TNG to make progress, unless Luke Howard
> 
> correct.

Good.

> >    thinks otherwise (he's doing the SAM-via-LDAP-with-win2k-schema work).
> 
> well, actually, we realy need to work out _microsoft's_ syskey2 for their
> password ldap fields.

Fine, then your SYSKEY idea becomes really low-priority ;)

(This from a lurker who hasn't contributed any code [well, one small
feature patch...].)

> and if we [or someone else, and releases code inder gpl] work it out, it's
> GOING into samba source code.

Sure. This particular case is an issue of compatibility with Windows
2000: supporting the use of Samba DCs as part of an ActiveDirectory
system (strange, eh? but doable).

> >  - TNG code freeze
> > 
> >    Don't do it yet; wait a few more weeks. So much progress is taking
> >    place that it seems worthwhile to wait a bit longer.
> 
> hm.
>  
> >  - 2.0.x->TNG merge
> > 
> >    This should be easy, actually: take smbd code from 2.0.x as is, drop
> >    all the MSRPC code save for the loopback to MSRPC daemons code.
> > 
> >    That's it.
> 
> not quite.  there are three things:
> 
> 1) clientgen.c, pwd_cache.c and other password-related code for NTLMv2
> support samba tng doesn't work without the support of this code.
> 
> 2) authorise_login(), password_ok(), pass_check(), smb_password_ok(),
> pass_check_smb(), all take const char* user, const char*domain - they
> shouldn't, these s houls be UNICODE - and return a NET_USER_INFO_3
> structure which is stored in the user_struct structure.
> 
> 3) user_structs are now not stored in memory of the smbd process, they are
> stored in a vuser.tdb database.  the key is the smbd pid + the smbd SMB
> vuid field.  this is so this info can be accessed from an msrpc daemon in
> order to be able to do a standard_sub_vuser() call. standard_sub_vuser(),
> and all... 20 or so uses of it, need to be updated, too, in 2_0.
> 
> YES, i damn well needed standard_sub_vuser(), i wouldn't bother modifying
> smbd code that is 2 years out-of-date, otherwise.

Yes, finish (2) and (3) and merge in the rest of smbd from 2.0.x + (1)
into TNG and you've got a TNG that is production quality for file
serving and still a bit alpha for domain serving but getting there.

> i think that's all.  if someone wants to take each of these things,
> starting in that order, there'd be lots of grateful people around.  oh and
> you'd be entitled to a samba team t-shirt, of course.

ah, uh, well, ah, I'm busy (scurries off).

:)

Nico
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.