New smb3 kernel server (ksmbd)(lkml.iu.edu)
lkml.iu.edu
New smb3 kernel server (ksmbd)
http://lkml.iu.edu/hypermail/linux/kernel/2108.3/05470.html
92 comments
Can't see why this needs to be in the kernel
It doesn't need to be. Samba works from userspace. This performs better because the fs primitives are in-kernel. It's also reportedly easier to maintain and easier to further optimize as part of the kernel. Everything's a tradeoff.
Same reason knfsd is in the kernel: performant file + locking access synchronized with the fs primitives.
The post indicates this is not to replace samba, but to improve the file sharing bits of it.
The post indicates this is not to replace samba, but to improve the file sharing bits of it.
Isn't the main reason for knfsd being in-kernel that it depends on inode number to file lookups? Does samba have the same problem?
The kernel nfs server is IME more robust than userspace options like ganesha, but that seems to mostly be a function of it being widely used - a kernel samba server doesn't have that advantage?
The kernel nfs server is IME more robust than userspace options like ganesha, but that seems to mostly be a function of it being widely used - a kernel samba server doesn't have that advantage?
No, Samba does not need to do inode to file lookups. There are no "open by inode" primitives in SMB1/2/3.
Dumb question: if this (or any other) kernel module crashes does the entire kernel?
Yup! And if an attacker hacks this module they can hijack the kernel. And it can probably be reached by anyone on the same network, or may even be exposed to the internet :|
You mean like the TCP/IP stack?
And if I could move that into user space without a hideous performance and/or compatibility penalty, I probably would.
Good point, but SMB has earned quite a reputation in this area.
Here the official mailing list mirror link:
https://lore.kernel.org/lkml/CAH2r5msoKV7qAgoKipa+QNDJ+xR83Y...
We shipped ksmbd a few months ago to a few million users. We had to iron out a few bugs, but otherwise it works really well (it supports SMBv3.1.1 and is faster than samba).
https://lore.kernel.org/lkml/CAH2r5msoKV7qAgoKipa+QNDJ+xR83Y...
We shipped ksmbd a few months ago to a few million users. We had to iron out a few bugs, but otherwise it works really well (it supports SMBv3.1.1 and is faster than samba).
Who are these millions?
So this is all really about workarounding the GPLv3. Sigh.
Saying that because the motivation is apparently that Free was "stuck" for non-descript reasons with "an old unsecure SMBv1 server", which, i'm going to guess, due to an entirely random coincidence, happens to be the latest version of Samba which was GPLv2-licensed. :(
Saying that because the motivation is apparently that Free was "stuck" for non-descript reasons with "an old unsecure SMBv1 server", which, i'm going to guess, due to an entirely random coincidence, happens to be the latest version of Samba which was GPLv2-licensed. :(
the wireguardification of the kernel! just kidding, I applaud this welcome performance boost, it's always been tricky to extract the most performance out of Samba, especially over high-latency links, although that's more of an SMB protocol issue than anything else, but hopefully ksmbd helps in that regard.
WOW! This is fantastic (potentially).
Can this be used as a file server to Windows / Linux / Mac clients? I don't need the AD part, but do need the file serving part that would integrate reasonably with a windows setup.
There was a golden period when Samba shipped on Mac, you could run Samba on linux, and consume it on all platforms (Mac / Windows / Linux) pretty easily.
Can this be used as a file server to Windows / Linux / Mac clients? I don't need the AD part, but do need the file serving part that would integrate reasonably with a windows setup.
There was a golden period when Samba shipped on Mac, you could run Samba on linux, and consume it on all platforms (Mac / Windows / Linux) pretty easily.
there are 7 condescending, mean, negative posts. ~4 neutral posts. this is one of 2 positive, happy posts, and by far the happiest. you deserve a god damned medal.
it's shocking what a bunch of sad sorry sacks there are about. everyone's a critic, conservative & afraid of change, unwilling to see uses. what a terrible crowd here.
yes, this is exactly for setting up a file server for Windows/Linux/Mac, without the AD part, without samba. i wish your positivity had a little stronger basis to it, knew a little better what you were excited about, but hey, given the pick of these negative nancies and you, mercy, i'd take your innocence any day.
it's shocking what a bunch of sad sorry sacks there are about. everyone's a critic, conservative & afraid of change, unwilling to see uses. what a terrible crowd here.
yes, this is exactly for setting up a file server for Windows/Linux/Mac, without the AD part, without samba. i wish your positivity had a little stronger basis to it, knew a little better what you were excited about, but hey, given the pick of these negative nancies and you, mercy, i'd take your innocence any day.
> ksmbd is a new kernel module which implements the server side of the SMB3 protocol. […] The bigger goal is to add new features more rapidly […] which are easier to develop on a smaller, more tightly optimized kernel server than for example in Samba.
That seems like a quite significant (external) attack surface to add to the kernel? (With plans on adding more)
That seems like a quite significant (external) attack surface to add to the kernel? (With plans on adding more)
Not directly related but aren't these the folks that are pulling out a lot of the insecure methods from the CIFS client? So that should be a good cleanup on that side. (ie, MD4?)
just don't run/load the module then?
i for one am super excited that i have a much lighter weight option available. for example, on my/my parents openwrt wifi routers to expose files with, in a way that other computers in the house can use.
my fear of security holes is pretty weak. this will be exposed inside the firewall only (at least at first). and i trust that by promoting & moving such a thing into the kernel, we'll have a very involved active community trying to make sure things are safe. we'll notice & catch exploits quickly once they start to be used. the message here of fear & uncertainty does not resound with me. quite the opposite. sunlight is not perfect but it has proven to be a progressive & very adaptive means to disinfect & secure within cybersecurity.
edit: wow, -2, some strong disagreement! not sure what ya'll are so afraid of!! why so conservative? doesn't this seem like progress?
i for one am super excited that i have a much lighter weight option available. for example, on my/my parents openwrt wifi routers to expose files with, in a way that other computers in the house can use.
my fear of security holes is pretty weak. this will be exposed inside the firewall only (at least at first). and i trust that by promoting & moving such a thing into the kernel, we'll have a very involved active community trying to make sure things are safe. we'll notice & catch exploits quickly once they start to be used. the message here of fear & uncertainty does not resound with me. quite the opposite. sunlight is not perfect but it has proven to be a progressive & very adaptive means to disinfect & secure within cybersecurity.
edit: wow, -2, some strong disagreement! not sure what ya'll are so afraid of!! why so conservative? doesn't this seem like progress?
Windows has a long and colorful history full of serious, remotely exploitable vulnerabilities made oh so much worse by the fact they're running inside kernel space. I'm sure there are plenty of people who don't like the idea of bringing this into Linux.
FWIW, these exploits are not all in legacy code. A recent SMB3 vulnerability "SMBGhost" used a lack of bounds checking of compressed data in the new SMB3 compression code, which can be triggered pre-auth.
If that bug is in a user space program, it's a bad bug, but you're at least not (unnecessarily!) opening up your entire kernel to RCE. Even assuming "many eyes find all bugs" some don't want to introduce the risk at all.
FWIW, these exploits are not all in legacy code. A recent SMB3 vulnerability "SMBGhost" used a lack of bounds checking of compressed data in the new SMB3 compression code, which can be triggered pre-auth.
If that bug is in a user space program, it's a bad bug, but you're at least not (unnecessarily!) opening up your entire kernel to RCE. Even assuming "many eyes find all bugs" some don't want to introduce the risk at all.
Slight tangent, but since the changelog further down mentions both cifsd and ksmbd: For all I know cifs is supposed to be the older name for the same thing (ie an older protocol version). But just like in this case, I still frequently stumble across both terms when reading about/dealing with it. So, is there actually still a difference between those two terms?
I thought the same thing when I saw both names mentioned. My understanding is CIFS is an older dialect of SMB that some servers/clients can still fall back on. Here's some key text from an article on the subject [0]:
> Most people, when they use either SMB or CIFS, are talking about the same exact thing. The two are interchangeable not only in a discussion but also in application – i.e., a client speaking CIFS can talk to a server speaking SMB and vice versa. Why? Because CIFS is a form of SMB.
> 1.) The CIFS implementation of SMB is rarely used these days. Under the covers, most modern storage systems no longer use CIFS, they use SMB 2 or SMB 3. In the Windows world, SMB 2 has been the standard as of Windows Vista (2006) and SMB 3 is part of Windows 8 and Windows Server 2012.
> 2.) CIFS has a negative connotation amongst pedants. SMB 2 and SMB 3 are massive upgrades over the CIFS dialect, and storage architects who are near and dear to file sharing protocols don’t appreciate the misnomer. It’s kind of like calling an executive assistant a secretary.
[0] https://www.varonis.com/blog/cifs-vs-smb/
[1] https://blog.fosketts.net/2012/02/16/cifs-smb/ (related)
> Most people, when they use either SMB or CIFS, are talking about the same exact thing. The two are interchangeable not only in a discussion but also in application – i.e., a client speaking CIFS can talk to a server speaking SMB and vice versa. Why? Because CIFS is a form of SMB.
> 1.) The CIFS implementation of SMB is rarely used these days. Under the covers, most modern storage systems no longer use CIFS, they use SMB 2 or SMB 3. In the Windows world, SMB 2 has been the standard as of Windows Vista (2006) and SMB 3 is part of Windows 8 and Windows Server 2012.
> 2.) CIFS has a negative connotation amongst pedants. SMB 2 and SMB 3 are massive upgrades over the CIFS dialect, and storage architects who are near and dear to file sharing protocols don’t appreciate the misnomer. It’s kind of like calling an executive assistant a secretary.
[0] https://www.varonis.com/blog/cifs-vs-smb/
[1] https://blog.fosketts.net/2012/02/16/cifs-smb/ (related)
CIFS may be old, slow and insecure.
But as the only SMB version that supports the "Unix Extensions" in practice, it is the only version I found which actually works between a Linux client and Samba serving a unix filesystem that is shared with other things, keeping the basic unix file attributes (symlinks, rwx permissions, etc) intact.
I tried SMB 2 and SMB 3, and many combinations of options on the client side and in Samba. Surely something would yield adequate if not perfect unix file attributes. But no combination worked adequately. Only CIFS.
In theory, SMB 3.1.1 has unix extensions that are supported by the Linux client module. In practice, I found this didn't work. Perhaps it will work one day.
Which is why I have a CIFS mount on my laptop at the moment. It's used every day for work, and I don't know what else I could use to get the same functionality.
You may be thinking, "this is what NFS is for". Alas it's not flexible enough. Samba is being used for its id remapping capabilities (and to a lesser extent to constrain permissions), which are sorely lacking in NFS if you don't have NFSv4, which the file server does not support. (Even if it did it would be difficult to set up adequately.) Ironically, Samba is re-exporting an NFS mount in this case, with Samba configured to provide the id-mapping and permissions-constraining that NFS won't do, and CIFS has to be used to maintain the unix file attributes.
But as the only SMB version that supports the "Unix Extensions" in practice, it is the only version I found which actually works between a Linux client and Samba serving a unix filesystem that is shared with other things, keeping the basic unix file attributes (symlinks, rwx permissions, etc) intact.
I tried SMB 2 and SMB 3, and many combinations of options on the client side and in Samba. Surely something would yield adequate if not perfect unix file attributes. But no combination worked adequately. Only CIFS.
In theory, SMB 3.1.1 has unix extensions that are supported by the Linux client module. In practice, I found this didn't work. Perhaps it will work one day.
Which is why I have a CIFS mount on my laptop at the moment. It's used every day for work, and I don't know what else I could use to get the same functionality.
You may be thinking, "this is what NFS is for". Alas it's not flexible enough. Samba is being used for its id remapping capabilities (and to a lesser extent to constrain permissions), which are sorely lacking in NFS if you don't have NFSv4, which the file server does not support. (Even if it did it would be difficult to set up adequately.) Ironically, Samba is re-exporting an NFS mount in this case, with Samba configured to provide the id-mapping and permissions-constraining that NFS won't do, and CIFS has to be used to maintain the unix file attributes.
Using CIFS (aka SMB1) is "like taking your grandmother to prom: she means well, but she can't really move anymore. Also, it's creepy and gross."
https://techcommunity.microsoft.com/t5/storage-at-microsoft/...
https://techcommunity.microsoft.com/t5/storage-at-microsoft/...
There is absolutely a technical difference, but in 2021 it has become a bit like kleenex. SMB/CIFS are used interchangeably by most folks. CIFS was the specific Microsoft implementation of the original SMB protocol.
https://www.varonis.com/blog/cifs-vs-smb/
https://www.varonis.com/blog/cifs-vs-smb/
In my experience, cifs is the client side, smb[d] is the server side.
On Linux, anyway. cifs has been in the kernel (supporting access to SMB shares, including through SMB 3.1), whereas the user-space samba has always been the only way to get SMB sharing (server-side).
edit: clarification
On Linux, anyway. cifs has been in the kernel (supporting access to SMB shares, including through SMB 3.1), whereas the user-space samba has always been the only way to get SMB sharing (server-side).
edit: clarification
I hope this doesn't displace Samba.
NFS is a pain to use specifically because it's compiled into the kernel, and reads config files that have to live in /etc. That makes it very hard to run or control as an unprivileged user. It also means that a file in /etc needs to be writeable. That makes NFS servers very hard to start, stop, and configure as part of a test bench.
Kernel NFS also essentially displaced all userspace NFS servers (that I'm aware of anyways). At least, I've never been able to get a userspace one to work.
I like Samba specifically because it's easy to configure, start, and stop from userspace. I don't want to see it get obsoleted.
NFS is a pain to use specifically because it's compiled into the kernel, and reads config files that have to live in /etc. That makes it very hard to run or control as an unprivileged user. It also means that a file in /etc needs to be writeable. That makes NFS servers very hard to start, stop, and configure as part of a test bench.
Kernel NFS also essentially displaced all userspace NFS servers (that I'm aware of anyways). At least, I've never been able to get a userspace one to work.
I like Samba specifically because it's easy to configure, start, and stop from userspace. I don't want to see it get obsoleted.
Samba is GPLv3, this is GPLv2 so they may be serving different communities ultimately. At least where I am GPLv2 - folks are MUCH more comfortable with that.
Not sure but one area would be embedded devices (think security camera with a SD card in it). This would really let them serve a file share for video browsing, without having to give out their keys to the devices themselves (GPLv3 is both viral and has all sorts of what are called anti-tivoisation provisions that means developers are more limited in what they can do with the code in terms of use).
Not sure but one area would be embedded devices (think security camera with a SD card in it). This would really let them serve a file share for video browsing, without having to give out their keys to the devices themselves (GPLv3 is both viral and has all sorts of what are called anti-tivoisation provisions that means developers are more limited in what they can do with the code in terms of use).
> anti-tivoisation provisions that means developers are more limited in what they can do with the code in terms of use
Developers are only "limited" from locking users out of their own device
Developers are only "limited" from locking users out of their own device
We need to be CRYSTAL clear here.
Developers are the ones contributing to these open source projects.
Developers are the ones picking which licenses to use (and which software to develop with).
Developers or their employers etc are setting the terms of sale with their user or regulatory agencies around product sales (which duty cycle limits, thermal cutoffs, RPM governors on engines, speed limits on vehicles like scooters and the list goes on and on).
Historically, open source didn't not have a restriction on use. In other words, even if Linus doesn't like military stuff, some govt contractor could use linux in a submarine. Similarly, if Linus things Trump was an idiot, he couldn't block trump from using Linux. Similarly, if a developer needed to set power emission limits on a device they shipped, or a governor or anything else they could lock the device so that user couldn't change power limits or duty cycles or other parameters. This is in many cases critical to these product sales.
Especially in industrial applications (but even automotive), the mfg and their developers often DOES NOT want users messing with the duty cycles, temp limit cutouts or other issues.
GPLv3 changes the calculation hugely here. Mfg's used to be basically free to use the software how they wanted, they just had to give back to other developers.
Under GPLv3 all this changes. GPLv3 requires folks to unlock devices, give up encryption keys. Because it is developers deciding on the licenses being used, GPLv3 is MUCH less acceptable to a lot of developers who don't want to be blocked from using projects they contribute to in the ways they or their employer wants.
So this is a very real limit on developers freedoms here. We keep on hearing from GPLv3 folks how much better the GPLv3 is - I and others disagree -it's a fundamental change to the GPL historic intent and function.
Developers are the ones contributing to these open source projects.
Developers are the ones picking which licenses to use (and which software to develop with).
Developers or their employers etc are setting the terms of sale with their user or regulatory agencies around product sales (which duty cycle limits, thermal cutoffs, RPM governors on engines, speed limits on vehicles like scooters and the list goes on and on).
Historically, open source didn't not have a restriction on use. In other words, even if Linus doesn't like military stuff, some govt contractor could use linux in a submarine. Similarly, if Linus things Trump was an idiot, he couldn't block trump from using Linux. Similarly, if a developer needed to set power emission limits on a device they shipped, or a governor or anything else they could lock the device so that user couldn't change power limits or duty cycles or other parameters. This is in many cases critical to these product sales.
Especially in industrial applications (but even automotive), the mfg and their developers often DOES NOT want users messing with the duty cycles, temp limit cutouts or other issues.
GPLv3 changes the calculation hugely here. Mfg's used to be basically free to use the software how they wanted, they just had to give back to other developers.
Under GPLv3 all this changes. GPLv3 requires folks to unlock devices, give up encryption keys. Because it is developers deciding on the licenses being used, GPLv3 is MUCH less acceptable to a lot of developers who don't want to be blocked from using projects they contribute to in the ways they or their employer wants.
So this is a very real limit on developers freedoms here. We keep on hearing from GPLv3 folks how much better the GPLv3 is - I and others disagree -it's a fundamental change to the GPL historic intent and function.
The intent of FSF was always to protect user freedoms - where users can also be developers - and not to protect developer freedoms - where developers are a separate class from users.
GPLv2 was share and share alike. Developers could work together on common software, and then each use it how they wanted within their orgs.
It also helped drive down proprietary forks.
Regardless of FSF desires, this is how it was used.
As GPLv3 was getting developed (in secret largely) communities like the Linux community started picking up on the big change coming and updated their license to be clear that Linux for example is GPLv2 ONLY (!) to avoid having the FSF change the usage and rules of their project on them.
It also helped drive down proprietary forks.
Regardless of FSF desires, this is how it was used.
As GPLv3 was getting developed (in secret largely) communities like the Linux community started picking up on the big change coming and updated their license to be clear that Linux for example is GPLv2 ONLY (!) to avoid having the FSF change the usage and rules of their project on them.
> As GPLv3 was getting developed (in secret largely)
The above is incorrect. GPLv3 was developed via a completely open process of development, documented very well here:
https://opensource.com/article/18/6/gplv3-anniversary
Apple lawyers participated. From the above link:
"Lawyers representing vendors' and commercial users' interests provided useful suggestions for improvements from a legal and commercial perspective, but these often took the form of making simply worded provisions more verbose, arguably without net increases in clarity. .. One lasting contribution of GPLv3 concerns changed expectations for how revisions of widely-used FOSS licenses are done. It is no longer acceptable for such licenses to be revised entirely in private, without opportunity for comment from the community and without efforts to consult key stakeholders."
The above is incorrect. GPLv3 was developed via a completely open process of development, documented very well here:
https://opensource.com/article/18/6/gplv3-anniversary
Apple lawyers participated. From the above link:
"Lawyers representing vendors' and commercial users' interests provided useful suggestions for improvements from a legal and commercial perspective, but these often took the form of making simply worded provisions more verbose, arguably without net increases in clarity. .. One lasting contribution of GPLv3 concerns changed expectations for how revisions of widely-used FOSS licenses are done. It is no longer acceptable for such licenses to be revised entirely in private, without opportunity for comment from the community and without efforts to consult key stakeholders."
The above is correct - this would take more to cover here but I'd quickly suggest maybe watching something from active developers?
You need to realize that the basic principles were NOT asked for by the major users of GPLv2. When initially discussed way before v3 they were rejected. There was no scoping of need here, certainly not by major projects like Linux.
https://youtu.be/PaKIZ7gJlRU?t=130
(start at beginning if you want more context).
Ubuntu went through this as well, and basically had to get the FSF to (privately) say that they wouldn't enforce the key release process for tivoization against Ubuntu. It was that or use the Microsoft shim.
It was just one sketchy / dicy deal after another. Crazy how wrong GPLv3 was in terms of a natural revision to v2 for developers. I doubt Linux has changed to GPLv3 or will personally, but we will see I guess. Good to see some GPLv2 options here that people can use in devices etc.
And the BSD's and MIT licenses took off as a result, GPL overall lost out as a result of the v3 mess in my view (as a GPLv2 fan that's a bummer).
Yes, the drafting part was "open" in the sense that lawyers got involved and the license got VERY very complex. If that's a win - go for it - most developers just passed on it.
You need to realize that the basic principles were NOT asked for by the major users of GPLv2. When initially discussed way before v3 they were rejected. There was no scoping of need here, certainly not by major projects like Linux.
https://youtu.be/PaKIZ7gJlRU?t=130
(start at beginning if you want more context).
Ubuntu went through this as well, and basically had to get the FSF to (privately) say that they wouldn't enforce the key release process for tivoization against Ubuntu. It was that or use the Microsoft shim.
It was just one sketchy / dicy deal after another. Crazy how wrong GPLv3 was in terms of a natural revision to v2 for developers. I doubt Linux has changed to GPLv3 or will personally, but we will see I guess. Good to see some GPLv2 options here that people can use in devices etc.
And the BSD's and MIT licenses took off as a result, GPL overall lost out as a result of the v3 mess in my view (as a GPLv2 fan that's a bummer).
Yes, the drafting part was "open" in the sense that lawyers got involved and the license got VERY very complex. If that's a win - go for it - most developers just passed on it.
Linus had no part in the drafting of GPLv3, so no I'm not surprised by that video at all.
I participated in the GPLv3 drafting, and your claim it was full of "one sketchy / dicy deal after another" is NOT correct.
You might not like how it turned out (and I myself have serious misgivings, mostly around the betrayal by the FSF in not using it for their own projects because they're frightened it will make them "unpopular") but it accurately reflected the wishes of the drafters at the time.
Nothing secret or sketchy about it at all.
I participated in the GPLv3 drafting, and your claim it was full of "one sketchy / dicy deal after another" is NOT correct.
You might not like how it turned out (and I myself have serious misgivings, mostly around the betrayal by the FSF in not using it for their own projects because they're frightened it will make them "unpopular") but it accurately reflected the wishes of the drafters at the time.
Nothing secret or sketchy about it at all.
First - the GPLv3 was NOT drafted in an open process.
IF they had bothered to ask folks shipping GPLv2 code what they would want in a GPLv3 they would have gotten a much smaller scope. Maybe some patent improvements and some other cleanups.
The idea that they solicited developer community input around the GPLv3 in terms of what it should cover is a joke. It really is a lie basically. Yes, they solicited users and activists, but not the actual folks giving their labor away for free. So they tried to basically trick a bunch of folks by hitching onto the v2 or later standard language - using a license with very different terms - SO SKETCH!!
It really illustrates how immoral and unethical the drafters of v3 were and left a sour taste with a lot of folks.
Some folks had a heads up around what would be coming - Linus got an early look and went immediately to GPLv2 only to protect against this attempted hijacking.
----
Once they did get it out - now FAR longer and harder to read, lots of special cases etc, they'd created a real problem, it was hard to work with this thing.
They kept on lying about having to release or not release encrypting / signing keys.
Ubuntu refused to use a v3 bootloader until they did some kind of backroom deal with FSF where FSF, as author of license, did some private interpretation Ubuntu could rely on. Ubuntu wasted a metric ton of time on this, and until they got the secret signoff were not going to budge (ahh, again a sign they ignored major dev communities).
I could go on, but it's not worth re-hashing. v3 basically ended GPL as the standard OSS license, I think folks are sick enough of it that MIT / Apache etc are going to be the future. Even the idealists among us learned some important lessons in the process.
I think GPLv3 and especially AGPLv3 will be the home of things like contributor licensed software to one company - it's basically unusable but they can call it "open source" sort of like Microsoft shared source stuff and then license commercially by keeping copyright in a for-profit vs in a community of contributors. If they can find devs willing to contribute under that - more power to them. But that wasn't the early model under GPLv2.
So the drafters fractured the GPL copyleft landscape (bad), messed up the popularity of this type of license (bad), didn't have the integrity to do a GPLv3 in keeping with v2 (bad).
It's kind of incredible, there was this AMAZING license in v2, I mean, folks had really consolidated around it in a fair number of major areas and ways. I sometimes can't believe that got torched for MIT and Apache (which really are not copyleft though they are open source).
----
Anyways, having failed with v3, I'm expecting they will try to back fit v3 by saying v2 is really v3? Look for some very strong pushback on that.
IF they had bothered to ask folks shipping GPLv2 code what they would want in a GPLv3 they would have gotten a much smaller scope. Maybe some patent improvements and some other cleanups.
The idea that they solicited developer community input around the GPLv3 in terms of what it should cover is a joke. It really is a lie basically. Yes, they solicited users and activists, but not the actual folks giving their labor away for free. So they tried to basically trick a bunch of folks by hitching onto the v2 or later standard language - using a license with very different terms - SO SKETCH!!
It really illustrates how immoral and unethical the drafters of v3 were and left a sour taste with a lot of folks.
Some folks had a heads up around what would be coming - Linus got an early look and went immediately to GPLv2 only to protect against this attempted hijacking.
----
Once they did get it out - now FAR longer and harder to read, lots of special cases etc, they'd created a real problem, it was hard to work with this thing.
They kept on lying about having to release or not release encrypting / signing keys.
Ubuntu refused to use a v3 bootloader until they did some kind of backroom deal with FSF where FSF, as author of license, did some private interpretation Ubuntu could rely on. Ubuntu wasted a metric ton of time on this, and until they got the secret signoff were not going to budge (ahh, again a sign they ignored major dev communities).
I could go on, but it's not worth re-hashing. v3 basically ended GPL as the standard OSS license, I think folks are sick enough of it that MIT / Apache etc are going to be the future. Even the idealists among us learned some important lessons in the process.
I think GPLv3 and especially AGPLv3 will be the home of things like contributor licensed software to one company - it's basically unusable but they can call it "open source" sort of like Microsoft shared source stuff and then license commercially by keeping copyright in a for-profit vs in a community of contributors. If they can find devs willing to contribute under that - more power to them. But that wasn't the early model under GPLv2.
So the drafters fractured the GPL copyleft landscape (bad), messed up the popularity of this type of license (bad), didn't have the integrity to do a GPLv3 in keeping with v2 (bad).
It's kind of incredible, there was this AMAZING license in v2, I mean, folks had really consolidated around it in a fair number of major areas and ways. I sometimes can't believe that got torched for MIT and Apache (which really are not copyleft though they are open source).
----
Anyways, having failed with v3, I'm expecting they will try to back fit v3 by saying v2 is really v3? Look for some very strong pushback on that.
"Dave, this conversation can serve no purpose anymore. Goodbye."
Some quick thoughts here:
Comments should get more thoughtful and substantive, not less, as a topic gets more divisive.
Please don't post shallow dismissals
I've worked to provide some background / context around my comments. Instead of indicating I was misinformed perhaps, that Ubuntu perhaps never was concerned about GPLv3 in a bootloader, we get a pretty content free dismissal. If you have little to add, perhaps just let the comment thread end?
These types of content free responses do little to advance a discussion on a topic.
Comments should get more thoughtful and substantive, not less, as a topic gets more divisive.
Please don't post shallow dismissals
I've worked to provide some background / context around my comments. Instead of indicating I was misinformed perhaps, that Ubuntu perhaps never was concerned about GPLv3 in a bootloader, we get a pretty content free dismissal. If you have little to add, perhaps just let the comment thread end?
These types of content free responses do little to advance a discussion on a topic.
> ...GPLv3 is...a fundamental change to the GPL historic intent and function.
That’s a pretty bold statement. As a FS developer since the 1980s (not just code, for example I wrote the library license) the GPL3 feels like it precisely captures the intent of the original GPL but updated for today’s world.
Of course in the interest of choice you aren’t forced to use GPLv3 code any more than you are forced to use a piece of proprietary code with license terms or cost you don’t like.
That’s a pretty bold statement. As a FS developer since the 1980s (not just code, for example I wrote the library license) the GPL3 feels like it precisely captures the intent of the original GPL but updated for today’s world.
Of course in the interest of choice you aren’t forced to use GPLv3 code any more than you are forced to use a piece of proprietary code with license terms or cost you don’t like.
Many developers disagree.
https://www.youtube.com/watch?v=PaKIZ7gJlRU
Gives just one example of folks who are active in this space thought. GPLv3 is very different than v2.
Edited: Some quick stats as well:
Permissive licenses are on the rise. In 2012, 59% of components' licenses were copyleft and 41% permissive. In 2019, that has fully swung the other way with 67% of components having permissive licenses and 33% copyleft. Permissive licenses face few restrictions on how others can use components.
MIT was the most popular license in 2019 at 27%. The MIT license lets folks do almost anything they want with the code as long as they attribute it and don't hold you liable.
Apache 2.0 jumped over GPL 3.0 in 2017 to number two and it's still there with 23%. It gives you patent rights while allowing modifications and distribution of larger works under different terms and without source code.
- Techrepublic
https://www.youtube.com/watch?v=PaKIZ7gJlRU
Gives just one example of folks who are active in this space thought. GPLv3 is very different than v2.
Edited: Some quick stats as well:
Permissive licenses are on the rise. In 2012, 59% of components' licenses were copyleft and 41% permissive. In 2019, that has fully swung the other way with 67% of components having permissive licenses and 33% copyleft. Permissive licenses face few restrictions on how others can use components.
MIT was the most popular license in 2019 at 27%. The MIT license lets folks do almost anything they want with the code as long as they attribute it and don't hold you liable.
Apache 2.0 jumped over GPL 3.0 in 2017 to number two and it's still there with 23%. It gives you patent rights while allowing modifications and distribution of larger works under different terms and without source code.
- Techrepublic
I don’t understand the point you’re making. You asserted that that v3 is inconsistent with the historical intent of the gnu project; I argued that it was not, based in part on my involvement going back into the 90s.
Of course you can disagree with me, but the choice various developers might make is unrelated to that. It merely shows that various people don’t agree with the goals of the FSF. Which may be interesting but has nothing to do with the licence’s fidelity to the FSF’s objectives.
Of course you can disagree with me, but the choice various developers might make is unrelated to that. It merely shows that various people don’t agree with the goals of the FSF. Which may be interesting but has nothing to do with the licence’s fidelity to the FSF’s objectives.
The GPL was always meant to ensure that the user had the freedom to change and use their software any way they like; v3 just clarified that you can't give users the code but then prevent them from actually running modified versions. By your logic, devs are "limited" by GPLv2 because they can't possibly bear having to expose their own proprietary code.
Under GPLv2, you can use the code base you contribute to how you desire.
With GPLv3 there are additional restrictions on how you can use the code base you contribute to.
With GPLv3 there are additional restrictions on how you can use the code base you contribute to.
Okay, I desire to run the software on the hardware that I literally bought to run it.
As do I. As a customer buying some hardware, I would of course like to have access to the software stack as well. And be it only for long-term support after the device becomes unsupported. But for various reasons, a lot of companies (and it is usually the decision by the company, not the employed developer) selling the products, don't want to give you this ability. Sometimes it is for making more money, sometimes it is for legal and safety reasons, just think of the automotive sector.
If a company decides to sell you a product with closed software, they will do so and GPLv3 won't change this. Not because they are not complying with the license terms, but because they won't touch any GPLv3 licensed software.
If a company decides to sell you a product with closed software, they will do so and GPLv3 won't change this. Not because they are not complying with the license terms, but because they won't touch any GPLv3 licensed software.
The point I'm making is that DEVELOPERS pick the license, and formerly for them they didn't lose much of their freedom by picking GPLv2, just others could also take code and do things.
With GPLv3 that changed. Others could still take code and do things, but now they COULDN'T do things.
Users desire is not part of this, and is a boring and old trope of OSS where users, doing no work and paying no money - make all sorts of demands. If that is the FSF attitude then good riddance to them, it's old and burns everyone out. They probably have attorneys going crazy and burning out people even more.
With GPLv3 that changed. Others could still take code and do things, but now they COULDN'T do things.
Users desire is not part of this, and is a boring and old trope of OSS where users, doing no work and paying no money - make all sorts of demands. If that is the FSF attitude then good riddance to them, it's old and burns everyone out. They probably have attorneys going crazy and burning out people even more.
Somehow I am quite sure "developers" are not the ones deciding to lock out their own customers here.
Well someone had to implement firmware that checks for signatures on software and doesn't provide the user any way to sign their own
Right, but the decision to implement this isn't made by the developer. It is made by the project lead/management.
Too bad it isn’t gpl2 compatible BSD so Apple could replace their shit version.
No question - that was a major regression apple side.
That said, I think apple DOES ship GPLv2 code don't they? Or am I mistaken there. I thought it was GPLv3 that was toxic at apple?
is there a CIFS GPLv2 or BSD client side implementation? This might not be what is needed to fix the Apple SMB situation.
That said, I think apple DOES ship GPLv2 code don't they? Or am I mistaken there. I thought it was GPLv3 that was toxic at apple?
is there a CIFS GPLv2 or BSD client side implementation? This might not be what is needed to fix the Apple SMB situation.
They don’t ship GPLv3 code at all - and they try there dardnest to get rid of GPLv2 if they can.
The old Samba was GPL2 I think but it got too old.
The old Samba was GPL2 I think but it got too old.
If it helps, as far as I'm aware Ganesha [1] is still widely used, supported, in some cases faster than the kernel implementation, and can be pointed at an arbitrary config file.
[1] https://github.com/nfs-ganesha/nfs-ganesha
[1] https://github.com/nfs-ganesha/nfs-ganesha
> That makes it very hard to run as an unprivileged user?
Huh? You can't run it as an unprivileged user at all.
You want NFS-Ganesha if you want a userspace NFS server. Development it active and it's the only OSS NFS implementation I've seen that can handle an Active-Active HA configuration with Kerberos.
Huh? You can't run it as an unprivileged user at all.
You want NFS-Ganesha if you want a userspace NFS server. Development it active and it's the only OSS NFS implementation I've seen that can handle an Active-Active HA configuration with Kerberos.
In theory you need CAP_SETUID and maybe a few other to run it with less privileges. That can also be done theoretically with another user than root if you can hack things appropriately. In practice the hacking part is hard.
Isn't NFS also dead? It basically believes you are root if you say you are.
And NFSv4 apparently requires Kerberos? WTF? Was it designed only for MIT use? Why can't they support simple things like SSH keys?
And NFSv4 apparently requires Kerberos? WTF? Was it designed only for MIT use? Why can't they support simple things like SSH keys?
NFSv4 uses idmapd with a defined "domain," unlike direct uid/gid mapping of earlier versions.
When the idmapd daemons on either side cannot agree on the domain, all users will be "squashed" to the default NFS user.
Root is always squashed, unless nosquash is specified in /etc/exports (which goes for earlier protocol versions as well).
NFSv4 [cleartext] does not require kerberos. Kerberos can be used to encrypt the data stream between client and server, but this can also be accomplished with stunnel over TLS (google "nfs encryption" for details).
When the idmapd daemons on either side cannot agree on the domain, all users will be "squashed" to the default NFS user.
Root is always squashed, unless nosquash is specified in /etc/exports (which goes for earlier protocol versions as well).
NFSv4 [cleartext] does not require kerberos. Kerberos can be used to encrypt the data stream between client and server, but this can also be accomplished with stunnel over TLS (google "nfs encryption" for details).
NFS is what you use if you want seamless file shares on Linux. Pretty much every other option has been junky or lost me data.
It depends on what kind of data is important for you.
In my Linux file systems (and also in my FreeBSD file systems), extended attributes are very important for me.
The older NFS versions (v2, v3 and early v4, before Linux 5.9) do not support extended attributes, so I was always forced to use Samba shares, which for me worked OK, including with the sharing between Linux and FreeBSD.
In my Linux file systems (and also in my FreeBSD file systems), extended attributes are very important for me.
The older NFS versions (v2, v3 and early v4, before Linux 5.9) do not support extended attributes, so I was always forced to use Samba shares, which for me worked OK, including with the sharing between Linux and FreeBSD.
I'm just happy with the files themselves being intact, but IME even that was difficult to achieve with non-NFS solutions. SMB was notoriously difficult to set up, and things like WebDAV or SFTP would have severe write loss problems when I tried to use them like an interactive local filesystem. NFS is rock stable.
A very clean approach to NFS authentication is using it in combination with wireguard.
With NFS you can limit access to certain IPs or IP ranges.
With wireguard you add authentication that these IPs are really the users/group of users.
Also it adds encryption to the actual file transfer.
The default for NFSv3 is to map client-side root to server-side nobody, unless you explicitly tell it not to. (Which I had to do once to run a diskless workstation with an NFS root filesystem.)
> I hope this doesn't displace Samba.
It doesn't seem to be the objective. For one, this is a very old version of SMB protocol (v3, while SMB doesn't have big releases anymore the current one is v4). Also, Samba have the user space tooling that this project explicitly doesn't want to reimplement. And it seems that both implementations are compatible with each other.
It does seem to me that the main objective here is to have a very efficient implementation of SMB for embedded devices.
It doesn't seem to be the objective. For one, this is a very old version of SMB protocol (v3, while SMB doesn't have big releases anymore the current one is v4). Also, Samba have the user space tooling that this project explicitly doesn't want to reimplement. And it seems that both implementations are compatible with each other.
It does seem to me that the main objective here is to have a very efficient implementation of SMB for embedded devices.
Samba versions don't correlate with the protocol versions.
The latest SMB protocol versions is 3.1.1.
The latest SMB protocol versions is 3.1.1.
gatling has basic Samba support and is really minimal.
If you start it without arguments it will just serve the current directory
If you start it without arguments it will just serve the current directory
what about ganesha?
I'm getting terrible performance exposing CephFS over samba, I wonder if this might solve those issues as well.
How are you using Samba -> ceph ? Are you re-exporting a fuse mount or are you using Sambas built-in vfs_ceph module ? The vfs_ceph module should be faster as it's essentially a protocol translator from SMB1/2/3 -> ceph.
The former, thanks! I didn't know about vfs_ceph, I'll check it out!
And thanks for your work on samba, it really is great and it's really enabling our way of working.
And thanks for your work on samba, it really is great and it's really enabling our way of working.
Samba ships with modules for ceph, gluster and gpfs.
Here's the info you need:
https://documentation.suse.com/ses/6/html/ses-all/cha-ses-ci...
Note the share definition:
[SHARE_NAME] path = / vfs objects = ceph ceph: config_file = /etc/ceph/ceph.conf ceph: user_id = samba.gw read kernel share modes = no
The "vfs objects = ceph" is the important part.
(if you're only exporting via Samba you can safely leave leases/oplocks enabled).
Here's the info you need:
https://documentation.suse.com/ses/6/html/ses-all/cha-ses-ci...
Note the share definition:
[SHARE_NAME] path = / vfs objects = ceph ceph: config_file = /etc/ceph/ceph.conf ceph: user_id = samba.gw read kernel share modes = no
The "vfs objects = ceph" is the important part.
(if you're only exporting via Samba you can safely leave leases/oplocks enabled).
I was wrong, I'm not using fuse, but instead the kernel cephfs implementation.
That article considers vfs_ceph to be legacy, and instead recommends to use the regular mount, but then does recommend to install samba-ceph and gives a configuration that does not mention ceph at all.
What does the samba-ceph package do if you're not mentioning ceph in the configuration, does samba detect the filesystem is mounted through ceph act accordingly?
I guess I should just try both approaches and see which one performs best.
That article considers vfs_ceph to be legacy, and instead recommends to use the regular mount, but then does recommend to install samba-ceph and gives a configuration that does not mention ceph at all.
What does the samba-ceph package do if you're not mentioning ceph in the configuration, does samba detect the filesystem is mounted through ceph act accordingly?
I guess I should just try both approaches and see which one performs best.
Try using the "legacy" method, just to ensure you can get it working.
Using "vfs objects = ceph" causes Samba to load a custom VFS module that translates SMB1/2/3 requests -> Samba VFS -> cephfs calls. That's why the share sets "path = /" (as it's not a local path) and then redirects all filesystem access via vfs_ceph.
Using "vfs objects = ceph" causes Samba to load a custom VFS module that translates SMB1/2/3 requests -> Samba VFS -> cephfs calls. That's why the share sets "path = /" (as it's not a local path) and then redirects all filesystem access via vfs_ceph.
I’d be more inclined to have syscalls that male Samba’s life easier (and Samba faster) but I’m not sure I want a full SMB server running in kernel space. Didn’t we all agree that servers running as root are a bad idea in general?
Right.
There was a time quite a while ago when people were writing in-kernel web servers, and they were performing better than userspace ones.
Then of course the response was to work out where the performance drop was coming from and add just enough flexibility to tweak the network behaviour from userspace to fix it.
There was a time quite a while ago when people were writing in-kernel web servers, and they were performing better than userspace ones.
Then of course the response was to work out where the performance drop was coming from and add just enough flexibility to tweak the network behaviour from userspace to fix it.
One of the goals i believe is to also allow some things like RDMA and other pcie to pcie comms for handling 100Gb+ speeds from direct nvme or similar storage. That's also really hard to do from userspace because it's dealing with hardware and resource controls. Not impossible to do, but certainly not easy either.
But then make syscalls for those functions and let Samba (or other file server) call them. The kernel should not be concerned with this if avoidable.
I am probably wrong, because the people behind this are much smarter than me, but, still, adding more application features to the kernel is not something I would encourage without some excellent use case and a good reason not to solve a performance problem by adding more hardware.
Given the option, I’d go with more hardware over making the software more complicated (but faster).
I am probably wrong, because the people behind this are much smarter than me, but, still, adding more application features to the kernel is not something I would encourage without some excellent use case and a good reason not to solve a performance problem by adding more hardware.
Given the option, I’d go with more hardware over making the software more complicated (but faster).
Feels like an antipattern. If you're doing high-speed stuff where a context switch to kernel mode and back would kill you, then you really want an RTOS with virtually no attack surface, instead of trying to hack it into the Linux kernel. Because with the Linux kernel, you'll be tempted to run less-secure code on there, because you might become overconfident in the kernel's security (which you've just co-opted by adding a custom in-kernel database engine or something).
Isn't there already a kernel-mode CIFS server in Linux via OpenZFS? (I haven't used ZFS on Linux so this might be a silly question. All my ZFS usage has been on BSD and Solaris.)
How is ZFS related to CIFS?
ZFS has an implementation of CIFS (SMB to be pedantic) which is included in OpenZFS.
From everything I've read, if you're on Linux you're better off not exposing the shares using the ZFS tooling and instead just use Samba (due to it's greater compatibility).
ZFS on linux uses the system tooling for SMB and NFS. Like if you `zfs share` a dataset, it modifies the system /etc/smb.conf or /etc/exports.
[deleted]
The storage industry has spent literally millions of developer hours over the past decade migrating functions from kernel to user space for reliability, performance, and security reasons. An SMB server in the kernel is not a good idea.