Slashdot Mirror
Tridgell Taking Samba Beyond POSIX
dW writes "The Australian hacker has been working on pushing Samba beyond the POSIX world and figuring out what work needs to be done to get Samba to support new filesystems such as XFS, ext3, and Storage Tank. The answer is nothing less than a complete rewrite of Samba's smbd code, which has become his latest pet project. Here's an interview with Andrew Tridgell on his latest Samba rewrite."
I think he means that instead of Samba presenting itself as a legacy CIFS file server it should serve files to a client expecting other file systems. So you could run Samba on AIX and tell your Linux box it's an ext3 connection.
Or maybe it's because the user level file systems on plan9 have made too much of a mark on me.
open, close, read, write & walk baby, s'all you need
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
Probably the same way that it isn't in windows.
thank God the internet isn't a human right.
The article was similar to Tridge's talk on the same subject at linux.conf.au in January - "towards full NTFS semantics in Samba."
The talk (in Ogg Speex audio format) and accompanying paper are on the linux.conf.au CD. There's a list of mirrors on their web site, both to mounted copies of the CD so you can download individual talks, and ISO images of the whole thing.
What he's talking about is taking advantage of "exotic" filesystems. Currently Samba just assumes it has a plain-old Posix filesystem like ext2 behind it, and does things less efficiently than might be possible
I'm not sure ext3 is a good example, but let's imagine it has a concept of transactions. Samba might be able to take advantage of that to provide a better implementation of CIFS, but to do that it has to know about ext3, more than that it's compatible with Posix.
Other examples: ACLs, case-sensitivity, multiple streams in files (like Macintosh resource forks), stuff like that.
I was on Monday and Tuesday on SambaXP where Tridge had talk about Samba 4. Also we discussed possibility of having completely Windows-compatible (and NFS v4) compatible ACLs on standard fs like XFS and ext3. Result was that Samba team needs a kernel interface for this so I'm going to hire some summer students for this and I expect some working code on autumn.
These are Posix ACL with clasical rwx attributes. Windows ACLs does have more ACL attributes.
This page has some information on Windows Alternative Data Streams:
s p
http://www.codeproject.com/csharp/NTFSStreams.a
No exactly. For example see NFS v4 ACLs:
READ_DATA Permission to read the data of the file
LIST_DIRECTORY Permission to list the contents of a
directory
WRITE_DATA Permission to modify the file's data
ADD_FILE Permission to add a new file to a
directory
APPEND_DATA Permission to append data to a file
ADD_SUBDIRECTORY Permission to create a subdirectory to a
directory
READ_NAMED_ATTRS Permission to read the named attributes
of a file
WRITE_NAMED_ATTRS Permission to write the named attributes
of a file
EXECUTE Permission to execute a file
DELETE_CHILD Permission to delete a file or directory
within a directory
READ_ATTRIBUTES The ability to read basic attributes
(non-acls) of a file
WRITE_ATTRIBUTES Permission to change basic attributes
(non-acls) of a file
DELETE Permission to Delete the file
READ_ACL Permission to Read the ACL
WRITE_ACL Permission to Write the ACL
WRITE_OWNER Permission to change the owner
SYNCHRONIZE Permission to access file locally at the
server with synchronous reads and writes
Some of them can help administrator a lot (especially when managing large system you can by "WRITE_ACL" delegate rights to sub-admins, by "ADD_FILE" you can restrict some BFUs doing mess on your system etc.
However I can help but wonder how these will be preserved if say the server is XFS and the Client FAT.
Hmm... it seems you didn't fully understand the article, and the problem currently being solved. First, let's create an example. We have a Win2k server serving files to a Win98 box. The Win2k server supports ACLs (in NTFS) and there's a bunch of access controls on the file. The user copies said file to their local box. Guess what, Windows must handle this somehow...
My point? This isn't Samba's problem! In fact, it's not even the same problem domain. Samba runs on the server side. What you mention is a *client side issue*.
The article is describing a method of emulating (or, more accurately, mapping) SMB (actually, probably NTFS) ACLs to ACLs in the native filesystem format. This is something Samba never did before because POSIX simply doesn't have the capabilities necessary to do this, and Samba was always targetted specifically at POSIX-compatible systems. BUT, filesystems like XFS, ext3, and others, have more advanced functionality in this area. So the work being done is to simply make the Samba backend more backing-store-agnostic, allowing it to take advantage of the advanced features in some of the more exotic filesystems out there.
But I'd wager the lions share of it's user base want samba to replace/supplement Win2k Server, and soon Win2003.
Aren't people reading this article? The work this fellow is doing is exactly along the lines of what you describe. The problem is that Win2k, et al, have a variety of features (like filestreams) which Samba simply can't implement because the underlying filesystem isn't capable of supporting these features.
So, this work involves modifying Samba (actually, re-architecting it) to allow it to take advantage of the advanced capabilities of some of the new filesystems out there. This will allow Samba to implement *more* of the SMB protocol, such as filestreams, advanced ACLs, etc. BUT, this is a lot of work because Samba is really inherently tied to POSIX, and all the limitations that implies. So, the work he's doing right now is to remove these dependencies and allow Samba to be more backing-store-agnostic.
XFS doesn't implement those permissions because they are not part of the POSIX permission set. There are ways (using extanded attributes) to add these types of permissions into XFS, but it isn't trivial and still does not match NTFS ACL semantics and behavior completely.
Samba 2.2 has ACL support - for XFS, at least. I know because I use it now. It's not just a TNG feature.
"Who's working on polishing up that ActiveDirectory and Kerberos stuff so I can continue to use my samba based PDC with WinXP."
A goodly number of us actually (myself included).
"There's nothing that can be done about it, it's his time, his decision. Still, it sure would be nice for samba to be a full member of a Windows 2000 domain."
Tridge has already implemented AD member support (and yes, a samba server can be a full member of a Win2k domain). The things holding us up from Win2k DC support have nothing to do with Samba or SMB but with LDAP (mostly schema at this point but we had to wait for a new-plugin mechanism in OpenLDAP called SLAPI) and Kerberos (if you think staring at SMB packets is painful, Krb5 packets are a thousand times worse...).
Right now, the rewrite is the best thing tridge could be working on.
int func(int a);
func((b += 3, b));