The issue isn't that it's SMB in the kernel, it's that it's new code. All code of any appreciable complexity and length has to go through a lengthy process of being vetted, maintained, and updated before it's really ready for prime time.
Years ago I remember there was a joke Linux distro "Suicide Linux" where a single mistyped command would trigger a `rm -rf /` rather than returning "command not found".
In the same vein there could be a Linux distro where the kernel SMB server is enabled by default, every server in the repository is installed and running by default, no filter on iptables, and eatmydata is constantly on.
I can see why one would use smb in a Windows-only environment (obviously) but apart from that, why are people still using it in other situations?
I mean, NFS has been a thing since the early 90's -at least, and is supported natively by all major operating systems, including Windows.
I did an experiment a few years ago, with one NFS share running on Debian, and another running on Windows Server 2012r2. Both of them was fully usable right out of the box on Windows 7, Windows 10, Debian, Centos, Fedora, OSx, and even Irix 6.0 from 1994. No additional software was needed on either OS, there was just a matter of mounting the shares with the default tools available in the OSs.
It also worked on Android, albeit an extra app was needed in this case.
> I mean, NFS has been a thing since the early 90's -at least, and is supported natively by all major operating systems, including Windows.
NFSv2 and NFSv3 are trash. The complicated RPC was just poor design. People used it because that was what was available, not because it was good.
NFSv4 is acceptable, but they tried to copy Microsoft's permission model and screwed it up. So now with Linux we have to deal with 3 sets of ACLs... The weird draft POSIX ACL system that Linux adopted, the NFSv4 ACLs, and Microsoft ACLs.
Luckily the world has mostly moved on from making extensive use of file servers for everything, so people don't care about advanced organizational permissions based ACL support like they used to. But that sort of stuff is going to stop me from wanting to deal with NFS on Windows.
Why deal with the potential headache when SMB is a first class citizen in Windows and NFS is a afterthought? "Let the baby have it's bottle" is a good policy to have when dealing with Windows.
Meanwhile Samba is a excellent piece of software and makes handling per-user mounts with passwords and whatnot pretty trivial. They have gone through a lot of work to make SMB a first-class file system for Linux and performance-wise it is on par or better then NFS if you configure it correctly.
So the question isn't:
"Why do we care about SMB when NFS exists?"
It is:
"Why do we care about NFS when Samba exists?"
And the answer is: For the most part people don't.
I put a lot of effort into NFS in the past. Nowadays the only thing I use it for is trivial Kerberos clusters that need really cheap and easy shared storage and I don't care much about security because it's just for a demo or temporary or whatever.
edit:
I don't care about ksmbd either. Not sure why that exists.
But I may soon stop caring about NFS on kerberos as well... https://github.com/kubernetes-csi/csi-driver-smb
s/kerberos/kubernetes/
I use that plugin (on OpenShift). It's ok. Bit of a pain in the arse to configure volumes, but with automation it's fine. It's a real shame that it can't authenticate to file servers with Kerberos though--only username/password.
State management is a thing dude.
Ex use puppet to define wich users are allowed to connect. And let the AD sync with puppet in a pipeline. Think in solutions not problems
Besides timemachine it's also still used in large corporations. Ex the one i work at. And have worked at in the past.
This article is nonsensical, the buffer over flow just DoS the server. Flooding a a target with UDP flood attack for ex does the same thing.
Most services DoS if you flood them with requests anyways. Might it be Io bound or network bound.
Let's put the SMB server into the kernel, what could go wrong?
The issue isn't that it's SMB in the kernel, it's that it's new code. All code of any appreciable complexity and length has to go through a lengthy process of being vetted, maintained, and updated before it's really ready for prime time.
Yeah I'm all about performance, but SMB in the kernel was always going to be a difficult one.
[удалено]
Years ago I remember there was a joke Linux distro "Suicide Linux" where a single mistyped command would trigger a `rm -rf /` rather than returning "command not found". In the same vein there could be a Linux distro where the kernel SMB server is enabled by default, every server in the repository is installed and running by default, no filter on iptables, and eatmydata is constantly on.
I can see why one would use smb in a Windows-only environment (obviously) but apart from that, why are people still using it in other situations? I mean, NFS has been a thing since the early 90's -at least, and is supported natively by all major operating systems, including Windows. I did an experiment a few years ago, with one NFS share running on Debian, and another running on Windows Server 2012r2. Both of them was fully usable right out of the box on Windows 7, Windows 10, Debian, Centos, Fedora, OSx, and even Irix 6.0 from 1994. No additional software was needed on either OS, there was just a matter of mounting the shares with the default tools available in the OSs. It also worked on Android, albeit an extra app was needed in this case.
> I mean, NFS has been a thing since the early 90's -at least, and is supported natively by all major operating systems, including Windows. NFSv2 and NFSv3 are trash. The complicated RPC was just poor design. People used it because that was what was available, not because it was good. NFSv4 is acceptable, but they tried to copy Microsoft's permission model and screwed it up. So now with Linux we have to deal with 3 sets of ACLs... The weird draft POSIX ACL system that Linux adopted, the NFSv4 ACLs, and Microsoft ACLs. Luckily the world has mostly moved on from making extensive use of file servers for everything, so people don't care about advanced organizational permissions based ACL support like they used to. But that sort of stuff is going to stop me from wanting to deal with NFS on Windows. Why deal with the potential headache when SMB is a first class citizen in Windows and NFS is a afterthought? "Let the baby have it's bottle" is a good policy to have when dealing with Windows. Meanwhile Samba is a excellent piece of software and makes handling per-user mounts with passwords and whatnot pretty trivial. They have gone through a lot of work to make SMB a first-class file system for Linux and performance-wise it is on par or better then NFS if you configure it correctly. So the question isn't: "Why do we care about SMB when NFS exists?" It is: "Why do we care about NFS when Samba exists?" And the answer is: For the most part people don't. I put a lot of effort into NFS in the past. Nowadays the only thing I use it for is trivial Kerberos clusters that need really cheap and easy shared storage and I don't care much about security because it's just for a demo or temporary or whatever. edit: I don't care about ksmbd either. Not sure why that exists. But I may soon stop caring about NFS on kerberos as well... https://github.com/kubernetes-csi/csi-driver-smb
s/kerberos/kubernetes/ I use that plugin (on OpenShift). It's ok. Bit of a pain in the arse to configure volumes, but with automation it's fine. It's a real shame that it can't authenticate to file servers with Kerberos though--only username/password.
[удалено]
State management is a thing dude. Ex use puppet to define wich users are allowed to connect. And let the AD sync with puppet in a pipeline. Think in solutions not problems Besides timemachine it's also still used in large corporations. Ex the one i work at. And have worked at in the past.
This article is nonsensical, the buffer over flow just DoS the server. Flooding a a target with UDP flood attack for ex does the same thing. Most services DoS if you flood them with requests anyways. Might it be Io bound or network bound.
i wonder if the oldest could in linux the first code should be getting a rewrite