SMB3 UNIX Extensions
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Alternative Title |
| |
| Title of Series | ||
| Number of Parts | 561 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/44543 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Kummer-TheorieField extensionSemantics (computer science)Standard deviationSelf-organizationConnected spaceKernel (computing)Point cloudInformation securityServer (computing)DataflowSpacetimeEncryptionTablet computerFeature spaceCommunications protocolInformationLevel (video gaming)Attribute grammarData storage deviceAsynchronous Transfer ModeIPSecWindowLevel (video gaming)Virtual machineSoftwareParity (mathematics)Multiplication signRevision controlCommunications protocolMechanism designField extensionWordSemantics (computer science)Directory servicePoint (geometry)Similarity (geometry)Sound effectData storage deviceEstimatorWave packetSlide ruleSoftware maintenanceService (economics)Matching (graph theory)Remote procedure callCartesian coordinate systemContext awarenessType theoryAdditionQuicksortComputer fileCodeServer (computing)Physical systemSelf-organizationStandard deviationLatent heatCloud computingFile systemPresentation of a groupEmailHill differential equationMaxima and minimaOffice suiteKernel (computing)Tablet computerComputer programmingTraffic reportingAddress spacePoint cloudEncryptionInformation securityOpen sourceInformationCASE <Informatik>Client (computing)Goodness of fitAutomatic differentiationSummierbarkeitComputer animation
09:31
Server (computing)Context awarenessOperations researchGroup actionClient (computing)Field extensionRevision controlCommunications protocolKummer-TheorieCodeCASE <Informatik>Sensitivity analysisSemantics (computer science)Gateway (telecommunications)Physical systemState of matterFile systemLevel (video gaming)Software bugOperator (mathematics)WindowTimestampContext awarenessLaptopRight angleCASE <Informatik>Film editingBitSoftware maintenanceConnected spaceServer (computing)Different (Kate Ryan album)Kummer-TheorieComputer fileMechanism designRegular graphCommunications protocolPoint (geometry)Slide ruleInformationDependent and independent variablesEncryptionClosed setFile systemOrder (biology)Random number generationFinite differenceSensitivity analysisOpen setContrast (vision)Standard deviationRevision controlClient (computing)SoftwareSingle-precision floating-point formatGroup action1 (number)Field extensionSound effectCodeSemantics (computer science)Arithmetic meanTerm (mathematics)Decision theorySimilarity (geometry)NumberSpeech synthesisMereologyMaxima and minimaSystem callShared memoryWordWeightComputer animation
18:56
CASE <Informatik>Sensitivity analysisContext awarenessKummer-TheorieGateway (telecommunications)Semantics (computer science)Physical systemState of matterFile systemInformationCommunications protocolStatisticsTexture mappingClient (computing)System programmingLatent heatLink (knot theory)Streaming mediaToken ringEncryptionAttribute grammarBlock (periodic table)Computer fileImplementationMereologyPoint (geometry)Information securityField extensionServer (computing)Duality (mathematics)Decision theoryStatisticsInformationGroup actionLevel (video gaming)WindowPattern languageFile systemServer (computing)Software developerSensitivity analysisSlide ruleSemantics (computer science)Streaming mediaCondition numberTime zoneSystem callCASE <Informatik>Auditory maskingClient (computing)GeometryInformation securityUnicodeMappingCommunications protocolCodierung <Programmierung>Intrusion detection systemAttribute grammarNumberCodeFreewareSet (mathematics)Physical systemBasis <Mathematik>Field extensionKernel (computing)Asynchronous Transfer ModeDirection (geometry)Computer fileBitVulnerability (computing)Roundness (object)Software bugData streamFlow separationParameter (computer programming)Link (knot theory)MiniDiscSingle-precision floating-point formatDigital electronicsToken ringSimulationEncryptionContext awarenessArithmetic meanMobile appMultiplicationSource codePresentation of a groupElectronic mailing listMathematicsProcess (computing)Game controllerService (economics)Real numberDecision theoryShared memoryInstance (computer science)Error messageRoutingCircleScripting languageLeakTheory of relativityEnterprise architectureBlock (periodic table)Kummer-TheorieNP-hardClosed setComputer animation
28:20
Communications protocolLocal ringPhysical systemServer (computing)Point (geometry)ImplementationSemantics (computer science)Link (knot theory)Field extensionCodeContext awarenessMereologyWikiKernel (computing)Client (computing)Software testingPoint cloudPrototypeNumberEmailSemantics (computer science)Data storage deviceProcess (computing)MathematicsLine (geometry)SimulationInformation securityWindowMessage passingMobile appPoint (geometry)Communications protocolData streamConnected spaceField extensionWikiKummer-TheorieLink (knot theory)Software testingFile systemClient (computing)Term (mathematics)Exterior algebraKernel (computing)Point cloudSingle-precision floating-point formatDirection (geometry)CodeContext awarenessStack (abstract data type)Computer virusNumberServer (computing)Task (computing)CausalityQuicksortMereologyStress (mechanics)Multiplication signStreaming mediaRight angleSinc functionFunctional (mathematics)MehrplatzsystemComputer fileGoodness of fitMultiplicationOnline helpSlide ruleReading (process)LengthSpacetimeTraverse (surveying)Error messageData managementInformationLevel (video gaming)Directory serviceAttribute grammarLocal ringHeegaard splittingComputer simulation1 (number)Electronic mailing list3 (number)OvalBranch (computer science)Computer animation
37:44
FeedbackComputer animationLecture/Conference
38:39
Task (computing)
39:24
Modul <Datentyp>SynchronizationData storage devicePersonal identification numberMultiplication signComputer animation
40:05
Euler anglesComputer animation
Transcript: English(auto-generated)
00:15
Okay, please welcome Jeremy and another presentation about Samba.
00:20
Thanks very much. So, I'm going to try and speak up because there's no amplification. Can you hear me okay at the back? Yeah? Okay, cool. So, my name is Jeremy Allison. I work for Google in the Open Source Program Office.
00:40
But I really want to make it very clear, there's my Samba.org email address on the presentation. And this is not a Google badge presentation, just in case there's any reporters hiding in the corners or something. This is not an official Google presentation. This is not what Google thinks. This is not what Google says, et cetera.
01:01
Any Google lawyers in the room should run screaming for the hills because nobody's reviewed it or seen it. So, having said that, let's dig into SMB3 Unix extensions. This is going to be a reasonably technical talk. It's not going to dive down as deeply as I could.
01:21
If you want more details, please feel free to ask questions or ask some more detail at any point. Stick your hands up and I'm happy to be interrupted and take questions in the middle of the talk. So, first of all,
01:40
let's go back one step and say, does everyone here in the room know A, what Samba is, anyone who doesn't know what Samba is? Okay, cool. And here SMB3. Is there anyone here who doesn't know what SMB3 is? Okay. So, we have one person. That's always good to say. So, SMB3 is the third version of a protocol originally developed by IBM,
02:03
taken on by Microsoft, and it is the protocol that Windows uses to talk to Windows to access files and directories. So, if you bring up your Windows Explorer and you attach to another server, you can see the files and directories.
02:21
SMB is the mechanism that's allowing that to happen over a network, and SMB3 is the third version of that protocol that Microsoft have developed, and it's actually quite nice, I think. So, why extend SMB3? Why add Unix extensions to it? Well, SMB3 is a Windows to Windows protocol,
02:43
so it doesn't have much accommodation for specific things that Unix machines need. So, originally, back in the SMB1 days, various vendors wanted to add features to SMB. Now, SMB doesn't have a standards organization.
03:03
It only has Microsoft, and what Microsoft does pretty much becomes the standard. So, it's evolved only to fit the needs of Windows to Windows. So, other vendors who needed to interoperate with Windows, sort of like HP and SCO before they went insane and started suing IBM or Linux, et cetera,
03:25
they thought, well, we already have an SMB redirector in our kernel, which is what allows us to mount the Windows systems. It wouldn't be so hard to extend this to talk to the SMB servers that we also have on our Unix systems.
03:41
And Sambo was the most ubiquitous server out there, and was the easiest to extend because you could just type the code in. So, SCO, HP, and a few of the vendors started proposing additions to SMB1 to make it work better between Unix to Unix.
04:02
Because if you're aware, Windows to Windows has case-insensitive path names, deleting files works differently, renaming files works differently, file locking is completely different, the semantics don't match. So, by extending SMB1, they could make the semantics match
04:21
Unix to Unix much better, so that Unix applications would get the semantics that they expected when they mounted a remote file system. And, excuse me, I'm going to have a, is the Ganesha maintainer in the room? He was earlier. Oh, okay, if he's not here, I can get away with more with my NFS jokes.
04:44
So, SMB1 Unix was actually better at Unix to Unix, POSIX to POSIX semantics than NFS. NFS has a boatload of hideous things in it, like silly renames, that basically hide the fact that it's a stateless protocol,
05:00
at least NFS v3, and doesn't work very well POSIX to POSIX. Well, SMB1 with Unix extensions had better fidelity for Unix to Unix than NFS does. So, plus, you know, NFS sucks and it should just die. So, I like this slide.
05:21
I made it because you can actually choose who you are, depending on which protocol you like. You know, you could say that NFS is Kirk's Screaming Khan, and SMB is saying, from hell's heart, I spit at the, or it could be the other way around. And the other thing I really love is, meanwhile, in the cloud,
05:42
we will add your biological and technological distinctiveness to our own. Your culture will adopt to service us. Resistance is futile. And no better summation of the cloud vendor, storage vendors, I could possibly imagine. So, yes, so, Khan and Kirk are having fun there,
06:02
while the Borg are out there waiting for us all. What happened with the SMB1-EX extensions? Well, they became a hideous train wreck. Why was this? Partly my fault. Partly the fault of a now Microsoft employee,
06:20
because I wouldn't say no to him. The issue was, there was no real oversight on what got added. And it was, well, if it works, it's good. It doesn't have to be protocol design, it just has to work, which is, you know, you can see the point in that. It was an enabler for some security problems.
06:42
And I'm going to go into those in a lot more detail later on. But allowing server-side symlinks, in other words, symlinks that are created on the server-side file system by the client, that the server then follows, is a recipe for security disaster. And I'll explain why in a little while.
07:04
So we just added anything we thought of. Oh, we want ACLs, right, we'll stick POSIX ACLs in there. We want encryption, okay, let's put transport level encryption in there. We want caseless, path name semantics, okay, that's a given, we'll put that in there. We want to have new info levels for POSIX semantics.
07:23
Even if there was a Windows info level, it was kind of similar. Yeah, let's just throw a boatload more info levels in. So, like I say, it was just ad hoc thrown together. Having said that, it had some very useful effects. I've been chatting to the Microsoft engineers who implemented SMB2 transport encryption.
07:43
They told me that they originally had terrible pushback from their internal security teams who said, no, no, don't do this at your file system layer. We've got IPsec to handle all security in the network layer. And as everyone knows, IPsec is widely adopted and easy to set up.
08:03
So that was a joke for people who don't have to support IPsec. It's terrible and doesn't work very well. So they were able to add transport level encryption directly into SMB1 just by saying, well, look at those open source guys. They've got transport level encryption, we need it for feature parity.
08:22
So that was actually quite useful. And the SMB3 transport level encryption is actually very well implemented and secure. So I'm happy about that. So, monorail, monorail, who needs a monorail? Sorry, Simpsons. A clean slate, we can design something glowing,
08:43
sliding into the future like the Springfield monorail. But one thing that we came away with, and one of the reasons this has taken a great deal of time, also because I'm kind of lazy and don't do things unless people are shouting at me.
09:01
But I finally came down with a philosophy of utter minimalism, which was that rather than the train wreck that was SMB1 Unix extensions, the SMB3 Unix extensions would only add things that we could not do any other way. So don't reinvent anything that SMB3 already has.
09:26
Just tweak and add in very small ways. Now, because the SMB3 protocol is actually quite nicely designed, that made this not too hard, actually. So what does this mean? Cuts down on the extra stuff you need to add.
09:42
Don't duplicate stuff. If you have an info level in Windows that returns create timestamps and whatever, don't add another POSIX level that does the same thing. You've already got that data. Get it the Windows way. Allow semantics that aren't 100% POSIX, but are kind of close enough.
10:04
And I'll explain a little more what that means in a later slide. Reuse the existing SMB3 features that Windows uses. So what does that mean? It means that we don't have to invent our own mechanisms for encryption. Windows already has ACLs and they are the love them or hate them.
10:25
And I certainly do hate them. They are the most widely deployed ACL mechanism on the planet. Everybody understands or OK, nobody understands Windows ACLs, but everybody uses Windows ACLs. That's probably the best way to put it. So they're very common and we should adopt the same.
10:43
Microsoft already added some features to SMB3, not widely used. Info levels and such that would make their NFS server work against the Windows back end file system. So when we have those mechanisms that Microsoft already invented,
11:02
just reuse them. Don't try and invent our own. Don't try and say as the better. Just say, hey, this is the Windows way of setting things. Let's use that. So what did Apple do? Let's let's contrast the Apple approach. Apple standardized on SMB2 and above for all of their file sharing needs.
11:21
They replaced their proprietary AFP file sharing protocol, but they kind of did it in a SMB1 UNIX extension similar way. In other words, I think they made a real mess of it. So what they did was they said, oh, we're just going to keep a regular SMB1 connection.
11:41
And then at the point that you actually attach to the network share, the first operation for an Apple server is a special magic open. And when you send that special magic open with a create context, I'll get into what create context are in a minute of AAPL, then the server knows I'm a Mac client and therefore I will behave
12:04
differently and do things, do different things. Now, that's basically the same kind of magic action horror. Send an info level that has no meaning other than to change the behavior of the server long term. And I'm trying to avoid that in SMB3 UNIX extensions.
12:21
So, you know, this magic action means the server must now respond differently to various different operations. And the effect of this is that poor Ralph from Cernet, who was the original AFP maintainer for the FP server on Linux, who now maintains the Apple compatibility with Samba.
12:41
Samba used to claim we were bug for bug compatible with Windows. Now we have to claim we're bug for bug compatible with Windows and Apple. So we have to duplicate the same bugs that the Mac server has in order to make the Mac's clients run. So this is a pain. So what did we end up with?
13:01
How should it look? So the nice thing about SMB3 negotiate is that you have this concept of negotiate concepts, context, sorry, which are basically arbitrary little pieces of data you can attach to the first packet. So we added a new one.
13:20
I originally thought we could get away without adding this context. So you send an empty context saying, hey, I am a client that is capable of talking POSIX SMB3 UNIX extensions. And if the server then replies saying, yes, I also can speak SMB3 UNIX extensions, then the client knows it's talking to a
13:44
UNIX capable server. So the nice thing about this is why is this there? Well, firstly, if the server doesn't respond with that, the client knows not to try any other POSIX or UNIX extensions.
14:00
The protocol spec says that they are non-mandatory. You can send as many of these contexts as you like, and the server only responds to the ones it understands, which is nice. And here's the kicker. Here's the reason why it's there. Theoretically, you don't need it because every single operation in SMB3 has to have a handle, and a handle has to have
14:23
contexts, and those contexts could specify SMB3 UNIX. So theoretically, I originally thought we can get away with simply doing context on the creates rather than on the initial negotiate. And then one of the Microsoft engineers in discussion on this
14:40
pointed out that we really need a create context because if you start sending these UNIX commands to the Windows server or to a server that you think might support them, and it doesn't respond or rather responds to the rest of the create but not the UNIX part, you don't know whether it
15:02
doesn't understand what you're sending it and is ignoring it, or whether it understands what you're sending it, but he's choosing to reject it on this particular operation. And so that's what the negotiate context is for. If the server responds to the initial negotiate context, you
15:22
know that the server is at least capable of doing the UNIX extensions, and then when you send them in further operations, if it refuses to do them, you know that the server is making a policy decision. It's not just, you can tell the difference between I'm ignoring you or I don't understand you, which can be kind of
15:42
important in protocols. And the other thing it allows us to do is if we mess this up and we need to rev the extension version number, which is possible, probably in fact, we have a way to say for the client to tell the server, oh, I want to speak, excuse me, UNIX extensions version two, not version one or
16:03
version three, et cetera. So the secret to making this work is essentially to leave alone all of the protocol that windows to windows speaks. So the first thing an SMB3 operation does is it says,
16:22
here's a path name. I want to turn this into a handle. I will then do operations on this handle. This turning a path name into a handle is done by a create, if you're familiar with the win32 API, that's the create file API. It's turned into an operation on the wire create and to modify the create where you can say things like, I want
16:43
to open us an older snapshot. I want to do this. I want to do that. You add these contexts called create contexts. And so the way the UNIX extensions are structured is such that adding the UNIX, I want to do a UNIX create turns on UNIX behavior, turns on UNIX behavior with renames,
17:04
deletes, locking, read, write, the rest of it for that handle only. So you can open a boatload of windows handles, then you can open a POSIX, a UNIX handle. Now, at least for SAMBA, this made it easy for us because we already have to handle the case where we're
17:20
serving SMB1 UNIX extensions and windows clients simultaneously. So we already have the code that can differentiate between the two. So I was kind of a cheat in that it was already easy for us. So what does a create context look like? It actually, I mean, I was thinking about showing the picture of it and whatever, but it really, it's pointless.
17:42
It's just a grid. It's just 128 bit random number. I generated a right on this laptop and then stuck in the code. If the server responds with a reply saying, yes, I understood this, then you know that you've got UNIX semantics.
18:02
So the first thing you have to run into is case ins, case sensitivity, windows to windows. It's case insensitive UNIX to UNIX. It needs to be case sensitive. So this is the first thing adding in that UNIX create context tells the server, I want you to pass this path name case sensitively as a proper UNIX to UNIX
18:24
connection would. Now, it is only a request for the server to do so. It is not mandated in the spec. Why is that? You might say, well, UNIX to UNIX has to be case insensitive, but that's not true.
18:40
If you look at Linux, imagine that you are mounting a NTFS file system on a USB stick or a USB drive or whatever. UNIX already has to cope with case insensitive path name lookups. So asking for UNIX create context on SMB3 and getting something back doesn't 100% mean that you've got case
19:03
insensitive semantics, case sensitive semantics. It just means you asked the server for that and it did its best effort. If you really want to know, did I get case insensitive? Can this share, can this file system give me case sensitive semantics?
19:21
There's a separate info level with a bit in it that says, hey, my share can do case sensitivity or not. So it's a best effort request. So the rest of the changes that you need are remarkably small. You do need one info level. I tried to get away without it, went back and forth,
19:42
but there is really a few extra pieces of information that you need to return from the UNIX stat system call that you can't get by doing just, you would have to do multiple round trips to Windows info levels to get the same thing.
20:01
And you still wouldn't get, you'd have to fetch ACLs for every single file, for instance, to get the mode bits. So it's a lot easier to have one very tiny modified info level that will return all the information a POSIX stat needs. For setting the mode for doing chmod, the easiest
20:20
way to do that is you have to support ACLs anyway, is you do a set access control list call with a special set of ACL masks that say user group owner. Microsoft already designed this. They already did it for their NFS server. So just reuse it. We already did.
20:42
POSIX ACLs, anyone here uses POSIX ACLs on the UNIX server? Tough. Windows ACLs, they're gone now. Windows ACLs only. Your POSIX ACLs will have to be mapped into the Windows ACLs best effort basis. As ZFS is becoming very, very common on FreeBSD
21:02
and Linux systems, yes, I know about the licensing. People still use it. That supports NFS v4 ACLs. I think XFS does. The world is moving to Windows-like ACLs. So you can set for SMB3 UNIX to UNIX, you can take the
21:24
incoming Windows ACLs, turn them into NFS v4 ACLs on the wire. That code is already in the Linux kernel to support NFS v4 servers. So let's just reuse that.
21:40
I'm tired of fighting Christoph Helwig over the Windows ACLs piece. Let's just put the NFS ACLs in. Other thing you don't get, no UIDs and GIDs. Everything comes back as Windows SIDS. Why is this? This actually was a big argument.
22:00
We ran around for many months over this. And the reason for it ultimately is any SMB client has to cope with mapping Windows SIDS security IDs, UIDs and GIDs basically, into UNIX numbers, UIDs and GIDs. The client already has to do this work. So I'm not going to make the server do it.
22:23
What you will end up with, and we did end up with this in the SMB1 UNIX extensions, is you ended up with being able to make POSIX calls to get UIDs and GIDs back. And then you would make Windows calls to get SIDS back. And you would be exposing the mapping that the server was using between SIDS and UIDs.
22:43
That mapping may have been different from the one that the client was using. And that lies the source of a million bugs and possibly security issues too. If you have one Windows SID that's mapped into one UID on the client and a different UID on the server,
23:01
that way lies madness and security errors. So eliminate the problem. Windows SIDS on the wire, nothing else. Changing ownership is simple. You just do a set ACL, you know, nothing different there, exactly as Windows would do.
23:22
So the file name handling is the largest change. How many people are familiar with Windows Streams names? Yeah, OK, a few of you. Windows has this hideous concept which I will explain in one slide why it is the worst idea in the world. But that will be the last slide of the presentation
23:40
because it's nothing to do with the rest of it really. I just want to show you why it's a terrible idea. So Windows has this concept of a special file name. You say colon colon name. And what that does is anything before that is the actual file. So, you know, foo, bar, baz is the file and then colon colon, stream one, stream two.
24:01
They become different independently seekable data streams within the file. This is the world's worst idea. So for the Unix to Unix in SMB3, don't expose that. Leave that in Windows hell. Just, you know, if you want a Windows stream, open a Windows handle without a Unix create context on it.
24:23
It would have been that Windows uses UCS2 encoding of Unicode, not UTF-8. It would, we are very tempted to say, oh, OK, if you get a win, if you get a Unix create context with the path name must be in UTF-8 just to make our lives easier, we decided to drop that.
24:40
It just complicates the path name processing. It means you have to handle path names coming in, in two separate encodings. And it's just easy to say, no, stick with Windows encoding. Windows encoding is good enough to encode any Unicode in UCS2. So, yeah, just leave that alone. Hard links are already supported by Windows. We don't need to add that.
25:01
You get goodies like snapshots, quotas and stuff from TimeWarp tokens for free. And you get all the other wonderful things that SMB3 gives you that David talked about, actually. Clustering, SMB direct leases, encryption, everything you want. So I've got to speed up a little, I think.
25:22
So what does, what's, what's kind of ugly? What's close enough? Extended attributes. Windows extended attributes are, they predate any of the SMB3 works. So they are ANSI character set, case insensitive encoded. I didn't add a separate Unix extended attribute call because EAs are,
25:45
well, to be honest, they usually ANSI encoded case insensitive. It's very rare that you would have a UTFA encoded case sensitive extended attribute. Maybe we'll run into some apps that need that. Maybe not for now. I'm going to leave it alone.
26:03
The other thing is EAs on Windows, and also on Samba, and they're not valid on symbolic links. And the only issue is SELinux uses this. But being as the most thing that, first thing that people do is usually turn off SELinux. I'm not terribly worried about that. Maybe we'll have to revisit that.
26:22
For weird things like FIFOs, block and character device files. Windows already has a way of encoding those. They needed it for the NFS server. Just reuse it. So I'm doing that. And so the hardest thing I had to do was basically to say no to the feature creep that people kept wanting to put in this thing.
26:43
So some people really wanted to add some crap into this, into this protocol. So why is following sim links on the server a bad idea? So there you've got an isolated route slash slave slash export. And then the client sends a relative path name. And while you're in the middle of processing that, if another client can
27:01
come in and replace that after you've processed past there and replace it with a sim link outside the safe exporters zone, you have a race condition and is a security hole. This was actually the security hole that I talked about in the presentation yesterday that Jan Horn, the Google developer found.
27:22
Um, but the whole, the reason that that's a problem is that the server transparently follows sim links. If that was not a sim link and the client could never create a sim link, that problem just goes away.
27:41
So I hate sim links. Um, they've been a security disaster in Samba. Sim links are kind of useful holdover when, you know, you had to add a new desk and you wanted to move some stuff over and create a sim link from where it used to be, et cetera. Great flexibility scripts, security disaster.
28:02
Um, as soon as SMB one could write those server side sim links and it was a terrible decision and it was my fault, uh, to store them as real sim links on the server file system. Um, it's, it's a horrible mess. It's convenient for NFS and SMB one servers.
28:21
And I absolutely want to forbid this in, uh, Unix extensions, uh, three. So how are we going to do sim links? Well, windows already has a concept of read pass points. Unfortunately, as in many things with windows, there are an over-designed mess. You can have read pass points on directories, on files.
28:42
You can turn a file into a read pass point. You can turn it back. There's all sorts of weird crap that you can do with it that I just don't want to deal with. So for SMB three sim links, SMB three Unix sim links, what I've decided to say is you can create a zero length file and turn it into a
29:02
read pass point and store the similar there in a special extended attribute, but nothing else. There was a minor modification needed to the protocol. I've still got to run past Microsoft to make sure that we can return the sim link error on traversal and storing sim links on this way breaks the local file system.
29:21
It means that local apps will not follow sim links created by SMB three clients. I'm okay with that. I'm okay with that because it's secure. So, uh, one of the easy parts we've already got working all the code for locking reads, writes, rename on link that already exists.
29:40
We did that for the SMB one Unix extensions. So it, with some tweaking, the code is remarkably small. A few thousand lines of code changes. Um, you can map the SMB three Unix create context onto an existing request Unix semantic in the SMB one stack.
30:01
And then, and then when they get built down below into the NTFS layer inside Samba, they kind of act the same way. Um, I need to write down this behavior to make it explicit and write tests to make sure that everyone understands what the protocol should do and be. So what works now?
30:21
Um, there's a Wiki link, a Wiki Samba.org link that explains what the details are on the wire protocol changes. Um, there is a Wireshark extension. Uh, I think Aurelion did, uh, he's just left though. Um, that actually will decode these extensions inside Wireshark.
30:44
Uh, here is my test branch, which I keep rebasing as master changes. This will be outside of master for, for a while yet. I'm hoping in a few months I can get more of it merged in. And then the Linux kernel, uh, Steve French is rapidly implementing this on
31:01
the kernel side of things, um, inside the Linux client. So the server side code is mostly complete in terms of functionality and features. Um, so the, the real work gets, you know, the 90% of the 10% left is to be done now is basically it needs to be splitting it split up into micro commits
31:20
so that it's an easy to follow upstream merge. Then I need lots of tests. I need to finish the client piece, which I haven't done yet. And I absolutely need to add lots and lots and lots and lots of tests. Uh, so this is going to take a while. The Linux client code already works, uh, is still evolving to match the server.
31:41
This is the big missing piece. The libsmb client code, it needs enhancing to negotiate and implement the SMB3 Unix extensions. So the API's are mostly there from, uh, SMB one. And, uh, to be honest, I could do with some help getting this finished. Uh, I, you know, I will do it.
32:01
It will just take longer if it's just me. So, so how do we know we've won? Um, wow. SMB3, uh, Unix to Unix replaces NFS. Yay! Come on! Um, so Steve French, who's, uh, the Microsoft Samba team member, he has
32:21
some spectacular numbers using the Linux client code to, um, the Samba server. Uh, he's really happy about that. We were very careful and collaborated with Microsoft. They are making no promises whatsoever, but we would really like other server vendors to implement these extensions and not make it too hard for them to do so.
32:44
And if you think about why Microsoft might be interested right now, they have greater than 50% Linux hosts in the Azure cloud, and they would really like those Linux hosts to be able to mount Azure SMB file storage over SMB3. And the closer to POSIX they can make that and Unix, they can make
33:02
that the more traction they think they're going to get in the Azure cloud. Which is fair enough. Um, there's another vendor, a third party SMB vendor, SMB3 vendor, who's also interested and started to implement. So I'm hoping that this will eventually take off. And eventually, once we've got it all written up, we'll publish
33:21
it as an addendum to the SMB3 spec. Uh, cause of legal issues, Microsoft can probably never publish it as an official Microsoft doc, but they can link to it and say, you know, we've carved out the info level space for these guys and they basically make it as official as they can, that's what I'm hoping. Um, oh, okay.
33:42
So here's my last slide and then we can go to questions. So, so here's going on about why alternate data streams are a terrible idea. You probably can't see that terribly well. If there's any Linux kernel file systems people in the audience, but what this is, this was actually a slide provided to me by Ted Cho, who is a Linux kernel file system person.
34:00
And it's his personal reason why alternate data streams, this, this ability to have multiple different streams inside a file is a terrible idea. What it shows is the windows task manager because windows has alternate data streams running a list of processes. And if anyone's familiar with windows processes, they're the standard ones, you know, spool SS, server host, you know, explorer, you name it.
34:25
Then at the bottom, there's a process running called myfile.txt. How's that happen? Well, what's actually running is a virus.
34:42
That was embedded inside myfile.txt in an alternate data stream with a name of, you know, my happy virus bitcoinminer.exe or something. And guess what windows will execute those directly.
35:01
So when alternate data streams only exist to gladden the hearts of CIA exfiltrators, who genuinely use these to steal data from people, which we've seen from the tools that they got hacked and dumped and virus writers. They're the only two people that I can see who have any use for alternate data streams.
35:21
So please, please, please do not add this to the Linux kernel. And I don't want to expose the ability to access them over SMB3 Unix extensions. Windows is bad enough. So does anyone have any questions and comments? You were very polite and quiet throughout the entire thing.
35:40
Yes. Oh, so the question is, with NFS, you can have a single mount, multiple users. Can you do that with SMB? You've been able to do that since SMB won.
36:03
Somebody go around and cuff him. Yes. It's every single connection. You basically do a new session set up, you create a new context ID and there you go. Multiple user, same connection. Yes. Any others? Yes.
36:28
So the question is, Microsoft really is pushing multi-channel on SMB3. Do you need to make any Unix extension changes? No, we get it for free. This it's, it's just a speed up feature.
36:41
We already have multi-channel in Samba. That's one of the reasons that I think Steve may have implemented multi-channel in the Linux client. I'm not sure, but that's one of the reasons why we can get wonderful performance. Yes. Question. So is there any chance of getting something like Linux iNotify over SMB?
37:01
Well, good news for you. It turns out that Linux iNotify was based on the existing Windows Notify, which has been in since, you guessed it, SMB won. So yes, that's a, cuff your friend for you, for me, will you? So yes, that's another feature that has been in the protocol since time immemorial and
37:23
we will continue to enjoy the benefits of just by existing in the same space. Yes. Any other questions? Oh, cool. Well, I guess everyone wants to go and have some beer. Well, thank you very much.
37:44
Sure. To provide some feedback to Jeremy Starks on cost and not art. Yes, please. Thank you. Very well done.
39:57
I'll just turn it on because we don't have a PA anyway. I just put it in my pocket.
40:01
Okay. Yeah, I'll give you time hints. Okay.