User: Password:
|
|
Subscribe / Log in / New account

Releasing Samba 4

Releasing Samba 4

Posted Dec 1, 2011 8:24 UTC (Thu) by Fowl (subscriber, #65667)
Parent article: Releasing Samba 4

I don't understand why all of those features would *ever* be in one daemon; they certainly aren't on Windows!

From memory, the file server is in kernel mode, the LDAP/Authentication goop, DNS, WINS, DFS and printer servers are separate user mode services while named pipes/rpc/mailslots are spread between both.

While not having a great depth of knowledge about Samba-the-software or Samba-the-prokect I'd imagine there is slightly more to the story. The note that Samba has two conflicting "markets" is very true: enterprise v consumer/SMB/embedded.


(Log in to post comments)

Releasing Samba 4

Posted Dec 1, 2011 10:18 UTC (Thu) by trasz (guest, #45786) [Link]

Yup. And that's one of the reasons Samba was dropped by e.g. Apple (they have their own userland SMB server implementation now) and Sun (they have their own in-kernel SMB file server). It would be nice for someone to create userland implementation using the latter, btw - it's small, simple, secure and it even handles ACLs properly.

Releasing Samba 4

Posted Dec 1, 2011 11:32 UTC (Thu) by jengelh (subscriber, #33263) [Link]

*nod* *nod*. One big fat program-process is so DOS-era-ish. Many system daemons, e.g. cups, postfix, other MTAs, split up in some form, either for reasons of pluggability, better scheduling, selective restart, or in fact debuggability. In fact, even desktop environments do that. XFCE, KDE, even icewm, is not a single process.

I recall that 5-7 years ago, smbd subprocesses could go into an infinite loop ("Transport endpoint not connected" over and over and visibility in top(1)) if a Windows client suddenly disconnected in some form. Were samba, or even just smbd, a single process - it would have been hard to kill the thread. Were samba/smbd just one thread - it would have taken down the entire fileserving.

Releasing Samba 4

Posted Dec 1, 2011 13:59 UTC (Thu) by pj (subscriber, #4506) [Link]

Yeah, it sounds to me like they don't need to so much to integration into one big process as they need to integrate them all into a common message bus or something. D-Bus springs to mind, but standardizing on any kind of IPC would be a win - then they can all stay separate processes and just... talk to each other.

Releasing Samba 4

Posted Dec 1, 2011 18:34 UTC (Thu) by jra (subscriber, #55261) [Link]

Apple was dropped by Samba for purely religious (GPLv2 vs GPLv3) reasons. Trust me on that.

Sun had bought the Procom code and integrated it into their kernel (badly). As for "it even handles ACLs properly" don't make me laugh. I communicate with Nexenta quite a lot. Let's just say there are some ACL "issues" with that code still being worked on (that's not to say there aren't ACL issues with Samba, I work on them myself :-).

Jeremy.

Releasing Samba 4

Posted Dec 1, 2011 19:58 UTC (Thu) by trasz (guest, #45786) [Link]

Yes, there are some ACL issues. But it's still lot better than with Samba, which does all kinds of sick stuff to work around lack of compatible ACL model in Linux, and which, generally, does not work at all.

Releasing Samba 4

Posted Dec 1, 2011 20:32 UTC (Thu) by nix (subscriber, #2304) [Link]

You may find your respondent (the coauthor of Samba), as well as a lot of Samba users, disagree with your somewhat contentious comment that ACLs in Samba 'do[] not work at all'!

Releasing Samba 4

Posted Dec 2, 2011 7:54 UTC (Fri) by trasz (guest, #45786) [Link]

Let me rephrase: while ACLs in Samba work in some specific, even if common, cases, they don't work in the general case. That's because it's impossible to "emulate" NTFS/NFSv4 ACLs on top of POSIX.1e ACLs, which is what Samba is trying to do - these two differ even in fundamental ways, e.g.in the way ACL entries are evaluated. In order to support ACLs properly Samba would have to either ditch support for systems that don't support NFSv4 ACLs natively (i.e. Linux), or just store the ACLs independently from the filesystem.

Releasing Samba 4

Posted Dec 2, 2011 18:51 UTC (Fri) by jra (subscriber, #55261) [Link]

You're obviosly unaware of the acl_xattr module shipped in modern Samba, and used by most OEMs.

This stores "pristine" Windows ACLs in an EA on the filesystem, and consults them before allowing access to the underlying file/directory. The mapping to underlying POSIX ACLs (for systems that don't support them) is done underneath this layer for compatibility with NFSv3 and system process accessing the same files.

Samba of course has a full mapping into NFSv4 (ZFS, or GPFS) ACLs, which will be supported on Linux once the "RichACLs" patch is accepted into the kernel.

So yes, ACLs *do* work in the general case in Samba, and many successful OEMs ship with them turned on.

Jeremy.

Releasing Samba 4

Posted Dec 5, 2011 9:40 UTC (Mon) by trasz (guest, #45786) [Link]

Yup, my bad. I didn't know about this module.

Releasing Samba 4

Posted Feb 8, 2012 7:19 UTC (Wed) by kaiser (guest, #82799) [Link]

It's my experience that most users want ACLs which interoperate with the native filesystem as well as NFSv3/v4--in other words, they want their permissions to be the same regardless of access protocol. In this respect I think Sun and Isilon did it right by integrating ACL/SID support directly into the kernel.

This fixes some minor interop. nits (group owners of files, for example) but also allows the Windows privilege model to be integrated as a first class citizen in the OS, and most importantly, allows for SIDs to be stored natively as the user's in-kernel credentials, which is a real boon for identity management/mapping across protocols, and for group policy (e.g. local groups). As a bonus, this allows any userspace CIFS processes to run without escalated privilege (e.g. switching to root for take ownership) which can be seen as a security risk.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds