No nua for Samba-3.0rc1?

[Tom Alsberg]

On Sun, Aug 31, 2003 at 09:39:12AM +1000, Andrew Bartlett wrote:
> On Sat, 2003-08-30 at 23:47, Tom Alsberg wrote:
> > <snip />
> > Why is this so now?
> 
> Because the idmap code (which allowed us to delay UID allocation,
> potentially forever) is no longer used for local accounts (including
> machines).

Well, didn't know that...

> > > To answer the original question.  the XXX_nua passdb backends 
> > > were all removed.
> > 
> > I suppose there is a reason they were removed.  Anyway, is it related
> > to some change in Samba somewhere else, or can I add sort of NUA 
> > functionality to my passdb backend and it'll work?
> 
> They were removed when their functionality was rolled into idmap.  Then
> idmap was rolled-back to just remote accounts.   A couple of developers
> (including myself) are interested in taking this concept forward again -
> however time pressures mean that this certainly won't happen
> particularly soon (and even then, this is an issue for past the 3.0
> release).

I see.  Well, hope the methods will be unified somewhen...

> > Does Samba actually do anything (run any code) as the UID of 
> > machines?  
> 
> Potentially it could, in the future.  As we start to move towards active
> directory, we will need to support this feature for genuine file
> access.  (Because machines can log in with kerberos).  Much sooner, we
> are going to need to face this for machines that log in with
> schannel.

Uh, need to read about schannel.  Isn't this just some secure
(encrypted) channel that CIFS will be communicated over?

> > Could I generally just be able to give all machines the 
> > same UID (say, that of nobody), (of course, taking care that they get 
> > unique SIDs/domain RIDs) and this way not have to give machines 
> > system accounts?  That's really the functionality I'm looking for.  I 
> > do not want to complicate matters with accounts for machines when 
> > they don't really need anything.
> 
> Because a machine (like any SID) may potentially own files,

Well, potentially, they can...  But mostly this wouldn't happen
(unless there are things like machine trusts), I suppose?  Can't it
sort of be ignored if not desired in a specific case (something like
not let any machine take ownership of or create files, and assume
nobody needs it) like my case here?

> they need to be represented by a real UID.  Having a one-to-many
> UID->SID mapping is just looking for trouble - we have too much code
> that assumes this is symmetric.

True...  Then, though, I didn't think any code which would in reality
ever be reached in regard to machine accounts cares at all about
UID's, but I suppose I was wrong.

> > I am pretty against creating accounts and removing them on the fly 
> > (actually I am not interested in administration from Windows either, 
> > but that's something different - not really "on the fly" per se).
> > Where does Samba need those accounts - what would happen if they just 
> > didn't really exist?
> 
> The current process allows their creation and removal without touching
> /etc/passwd, if that helps.

Meaning, in some alternative account database?

> At some point, the account must be created - there is interest in
> creating it in our passdb, and simply making that sufficient for the
> entire system (exporting the passdb to nsswitch). - but whatever you
> do, we must create the account.  (Again, such an export is a
> post-3.0 thing).

Well, say I do not care about access to those accounts from outside of
Samba (after all I didn't really want those from the beginning), and
that other attempts have failed, I could still just store them in the
passdb and not in the global pwdb (so Samba would see a user MACH$
with a UID and everything, and you might see processes running under
this UID, but it won't have a name or any information in the system
database)?

> Andrew Bartlett

  -- Tom

-- 
  Tom Alsberg - hacker (being the best description fitting this space)
  Web page:	http://www.cs.huji.ac.il/~alsbergt/
DISCLAIMER:  The above message does not even necessarily represent what
my fingers have typed on the keyboard, save anything further.