1 Jun 2004 01:06
Re: se-samba
<tridge <at> samba.org>
2004-05-31 23:06:18 GMT
2004-05-31 23:06:18 GMT
Russell, One thing to be careful of is to distinguish the right design for a se-linux enabled Samba in Samba3 and Samba4. The design of Samba3 is quite different from Samba4, and the approach taken needs to be correspondingly different. The design that Luke proposes is closely tied to Samba3, as that is what he is familiar with. Samba-tng uses the same basic design for file sharing as Samba3, as it is based on the same code. The main features of the Samba4 design that are relevant to you are: - backend isolation. Samba4 uses a "NTVFS" layer, which takes the place of the old VFS layer in Samba3. All POSIX/Unix filesystem assumptions are isolated into the backends behind this layer, so for example uid_t and gid_t will only appear in these backends. - The core code makes no calls to seteuid() at all. So if you write your own NTVFS backend you can choose not to use seteuid() if you don't want to. - async backends. On a per-call basis the backends can choose to answer synchronously or asynchronously. This allows you considerable flexibility in how you dispatch operations. It also solves the NT threads problem that Luke mentioned. - flexible process models. Samba4 comes with 3 process models, selectable at runtime, and you could potentially add another process model if you want to. The default models are "single" (with everything in one process), "standard" (a process per connection),(Continue reading)
> Upon re-reading the email I sent, perhaps I should explain the changes my
> patch makes to kerberos_verify() a little more clearly. The patch does not
> create a situation in which kerberos_verify would break, by changing
> kerberos_verify() to be keytab only. The patched kerberos_verify() works
> like this:
>
> FIRST PASS - checks the keys in the keytab, if it even exists. If a
> key works, great, the session succeeds.
>
> SECOND PASS - if the keys in the keytab fail, (for example if the
> keytab doesn't exist, the system admin doesn't have a correct reverse dns
> zone, etc.) Then kerberos_verify() tries to use the machine password from
> secrets.tdb to make keys, just like it the function did before the patch was
> applied.
>
> THIRD PASS - nothing left to try, NT_STATUS_ACCESS_DENIED is
> returned.
RSS Feed