New smb3 kernel server (ksmbd)
lkml.iu.edu
lkml.iu.edu
That seems like a quite significant (external) attack surface to add to the kernel? (With plans on adding more)
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?
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.
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.
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).
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).
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. :(
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.
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.
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).
Developers are only "limited" from locking users out of their own device
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.
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.
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."
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.
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.
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.
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.
With GPLv3 there are additional restrictions on how you can use the code base you contribute to.
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.
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.
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.
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
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.
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.
The old Samba was GPL2 I think but it got too old.
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.
The latest SMB protocol versions is 3.1.1.
And NFSv4 apparently requires Kerberos? WTF? Was it designed only for MIT use? Why can't they support simple things like SSH keys?
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.
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).
If you start it without arguments it will just serve the current directory
> 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)
https://techcommunity.microsoft.com/t5/storage-at-microsoft/...
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.
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
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.
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.
And thanks for your work on samba, it really is great and it's really enabling our way of working.
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 only = no 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).
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.
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.
The post indicates this is not to replace samba, but to improve the file sharing bits of it.
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?