No nua for Samba-3.0rc1?
alsbergt at cs.huji.ac.il
Sun Aug 31 10:31:04 GMT 2003
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
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
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
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
> Andrew Bartlett
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.
More information about the samba-technical