Posts by Jeremy Allison 128 publicly visible posts • joined 19 Oct 2008
When I was at Google I pitched them helping to improve Samba-Active Directory code to get feature parity with Microsoft AD.
I could never get any traction internally. Now we see the results unfortunately. At least the Sovereign Tech Fund (in Europe) is funding Samba:
https://www.theregister.com/2024/10/01/freebsd_and_samba_funding/
Not the AD code yet, but I have hopes :-).
I offered to go with Linus to Sao Paulo zoo once to help him avoid having to meet Lula, the president of Brasil which he really didn't want to do :-). I did so only on the condition he do an interview with me. I was fed up of people asking Linus about Linux, so I only asked him questions about the Sinclair QL, which both he and I enjoyed. Interview is still available on youtube here:
https://www.youtube.com/watch?v=05pgVwzAZ6k
It's.. complicated. Right now there's no integration between ksmbd and Samba, although we collaborate on SMB3+POSIX extension development.
Samba is a large and old project, with many procedures in place to try and prevent accidents like this (although we're both written in C, so until we can port to a safer language - which will probably never happen - there will *always* be disasters like this).
Having said that IMHO the kernel cifsfs and ksmbd code have some quality issues which come down to insufficient code review practices. I have complained long and bitterly about this in the past and the people involved are well aware of my opinions.
Take a look at Samba's gitlab page:
https://gitlab.com/samba-team/samba/-/merge_requests
Every potential commit has to go through a full pipeline continuous integration build (look here for examples):
https://gitlab.com/samba-team/samba/-/pipelines
and all commits must have 2+ Samba Team engineer review and sign-off before merging into the upstream codebase. Currently I don't see something similar for cifsfs and ksmbd. I'd be a lot happier if they had something like this.
> "Samba usually has odd performance problems that come with being an ancient Apache project."
What are you smoking, and can I have some please ? :-).
Samba was started around 1992, before Apache was a gleam in anyone's eye.
As for performance, putting something in the kernel isn't an automatic "go faster" switch for the processor. See here for details:
https://samba.plus/blog/detail/ksmbd-a-new-in-kernel-smb-server
Oh look. *ANOTHER* symlink toctou vulnerability. When will we finally admit that the addition of user-creatable symlinks has been a disaster for POSIX and secure coding ? I will stand my ground and claim it is *IMPOSSIBLE* for application developers to safely use the POSIX filesystem API securely in the face of symlinks. Simply can't be done correctly.
At lease Microsoft learned their lesson when they added symlinks to NTFS, and they made the creation of them Administrator-only.
That one simple change probably saved them *YEARS* of symlink toctou vulnerability fixes, if it's even possible to fix them all.
SONOS v2 includes SMB2+ support. It's only the old SONOS v1 boxes that only do SMB1.
Don't get me wrong, I'm not incredibly happy with this as I have many SONOS v1 boxes and no way am I giving them any more money, but they have added SMB2+ support (finally), if only for the latest releases.
I'll probably go the SMB2+ mount on a Raspberry PI re-exported via SMB1 to my old SONOS kit.
Argghhhh. Don't remind me. I'd successfully blocked pcNFS out of my memory :-). I used to have to support that PoS at Sun. It's existence is one of the main reasons Samba exists today (I'd left Sun, needed a cross platform network file system and someone suggested pcNFS. I restrained myself and didn't hit them. So I went looking on the (early) Internet and tridge announced the first version of smbserver. The rest is history:-).
I'm planning a blistering broadside bludgeoning (as it's 'El Reg, gotta use alliterative headlines :-) on the concept of symlinks at this years SambaXP conference.
https://sambaxp.org/
(it's virtual, so you won't have to travel to Germany to attend). symlinks have ruined the POSIX filesystem API. I'm going to explain why, and talk about what can be done about it.
If you're running a post Samba 4.8 server you're safe, even though the proof of concept code reports it as vulnerable (the PoC code only tries the logon, it doesn't actually try any of the activities that the default Samba setting of schannel required prohibits). Better to be safe though and upgrade to the version that removes the false positive from the PoC code.
More details here:
https://www.samba.org/samba/security/CVE-2020-1472.html
Back in the day, working on porting my GEM implementation to the Amiga to port Kuma K-Data over from the Atari ST to the Amiga, we noticed that (and I can't remember the exact details now) if you dragged an icon around on the stream at the same time it was doing a SCSI disk transfer your disk got lots of nice copies of the icon bitmap written all over the places where your data should have been.
The problem described in the article sounds horribly familiar.. :-).
I’m affected by this to the tune of 3 Play:5’s and 3 Connect’s, so I’m not a disinterested bystander.
Trying to take a step back and look at this - I think the fundamental mistake Sonos have made here is that they thought they were an electronics device company. But they are selling devices that allow people to connect to *music*. That makes things different to a phone or a TV, which are essentially seen as replacable and upgradable objects.
Music is different. Music affects people on a deep emotional level. The best audio brand names get this. They sell an *experience*, not hardware.
I think Sonos used to get this, but maybe the upper management have changed to people who thought they were in the electronics business. They are not, and they are about to discover this fact very painfully. I doubt the company will survive this. People are perceiving this, rightly or wrongly, as Sonos trying to take their music away (I know that is my gut reaction too).
They should have hired ex-Apple execs. Apple would never have made this mistake. They understand what they sell and it’s not hardware.
Open Source / Free Software is not a business model.
I've been doing this for nearly 30 years, getting paid for all of it. You don't create the software and Open Source it to make money, you create the software as it's what you need for yourself. If you Open Source it then others can help you. Only if it's any good will people start paying you to maintain it.
This whole idea of:
1). Open Source
2). ????
3). Profit !
Is worthy only of underpants gnomes thinking.
Samba developer here, responsible for some of the CVE's you're laughing at :-).
Yes, complex software has security bugs, especially if it's written in C. The measure of a project is how it handles them though. I'd argue the fact we report and fix our CVE's makes us *more*, not less trustworthy.
There's no hiding your bugs in FLOSS code.
I agree with you on waf though, but most of the Team members just love python code, so what can you do :-). If I'd had my way it'd probably have been cmake instead, but you have to compromise with your colleagues to get anything done at all.
If you contribute to FLOSS code you'll know what I mean :-).
> "you might as well use Samba v4 (I assume we're ignoring the fact it's based on Microsoft code)"
A correction. Samba is not, and has never been, based on Microsoft code. (Well, now we have a Microsoft engineer on the Samba Team I suppose his changes could now be accurately described as such, but he writes new code, not cut-n-paste from the Microsoft git repositories :-).
Jeremy Allison,
Samba Team.
In the respect of there not being samba.org supplied graphical configuration tools or ease-of-use features. We tried that with swat (the Samba web config tool) and it didn't end too well.
I'm happy it is easy and works out of the box for you, that's what we aim for :-).
I'll take Samba, as it's the one I know most about. Samba actually is "there", if by "there" you mean active use in many, many OEM products. It's not "there" as a general out-of-the-box user-installable Windows server replacement, that's probably true, but over the years I think we're realized that's not exactly where we want to be. The argument is "are we a product" or "are we a set of technologies". I personally think we're a set of technologies that other people use to build products, though opinions can differ of course.
I guarantee there are many many commercial products that you use daily that have Samba embedded in them (many cloud storage gateways as well as on-premises storage for example). So yeah, we're "there" in that respect.
Wine is becoming the same via Valve investment in Steam on Linux I think. That's their way forward. It's harder for LibreOffice.
You guys should really reach out and check your sources before posting drivel :-).
This is based on libsmbclient (aka Samba) integrated into ChromeOS.
https://www.samba.org/samba/docs/current/man-html/libsmbclient.7.html
It's not like we're hard to get in touch with..
https://www.samba.org/~jra/
Not true. There are several engineers here (including me). I had a chat yesterday with Paul McKenny (he of the RCU code in the Linux kernel). He showed me some amazing stuff to do with formal proofs around the Linux kernel memory barrier logic. We are in the minority though :-).
LDS wrote:
> "The EU ruling did more - it forced Microsoft to document its APIs and made them publicly available"
Not API's, *PROTOCOLS*. There's a *BIG* difference - although no one seems to understand why (I blame lack of technical education in schools :-).
No one gave a monkeys about their API's (unless you're writing code for Windows, in which case why do you care if other systems are successful or not), they are *useless* for Open Source, it's the on the wire *PROTOCOLS* that allow interop or not.
Trust me, I know what I'm talking about w.r.t. to EU vs Microsoft case :-).
Even in a cloud-first world people still use SMB, even if only with legacy apps. There's a reason that Microsoft allow direct SMB access into the Azure Cloud.
Many of the cloud-gateway vendors I'm sure people are avid fans of use Samba under the hood to gateway existing useful applications into backend cloud storage.
We have some life in the old dog yet ! :-).
Is that the Gluster of Ceph VFS module ? Sounds like the gluster one. That's a design bug in the gluster client libraries IMHO. They are assuming only one process connects from a client and so are profligate with resources. I think Red Hat is working on fixing that.
"REAL programmers do not NEED to do "garbage collection". They understand that for every 'malloc' or 'new', there must be a 'free' or 'delete'. And buffer sizes must be CHECKED. etc."
Samba uses the talloc library (invented locally) for this purpose. Check out https://talloc.samba.org/talloc/doc/html/index.html . It's a really nice piece of code which has stack/heap smashing protections etc. Lots of non-Samba code in Red Hat/Fedora also uses it.
Buffer overruns are harder, for much of SMB1/2/3 it's hard to auto-generate, as the protocol isn't defined in an interface definition language. Our DCE-RPC code is auto-generated and buffer overrun checked, as our IDL compiler (pidl) does this for us.
Unfortunately, due to C, these kind of bugs will always be with us. All we can do is be eternally vigilant and review everything.
It states: "Samba's developers have detected exploits", that should be "Samba's developers have *NOT* detected exploits", because we haven't.
Never say never, but I can't see a way to exploit this (not that I'm an exploit expert). But better to fix than leave any possibility around.
Remember, the Linux Foundation is a USA 501(c)(6) non-profit, organizing on behalf of its members, *NOT* the Open Source or (heaven forbid) the Free Software community.
Anyone who is surprised at this simply hasn't been paying attention.
Other notable 501(c)(6) non-profits include the MPAA and the RIAA.
Now are you getting it ?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
