Linux 6.6's in-kernel SMB networking server graduates

The next release of the Linux kernel, 6.6, has hit release candidate status. As usual, it contains a number of new features, but we think one has more potential ramifications than all the others put together. Linus Torvalds announced kernel 6.6-rc1 last night, and it includes the KSMBD in-kernel server for the SMB networking …

[Paul Crawford]

From a cited article:

However, the Samba team has moved active development of the project to the more strict GPLv3 license, which prevents Apple from realistically using the software commercially.

Given samba is a stand alone program, why is this an issue? Do Apple want to change it in some way and make it run only if signed and deny anyone from running an unsigned version?

[teknopaul]

KMods

This sort of stuff in the Linux kernel used to worry me.

Now it's reassuring.

[bazza]

Huh?

From the article:

As one comment on Hacker News said "Unless this is formally proven or rewritten in a safer language, you'll have to pay me in solid gold to use such a CVE factory waiting to happen."

Well, I know what they mean, but being paid in solid gold is only of any additional remunerative value if one is given sufficient ounces to be worth more than one's salary!

[bazza]

Age Old Architectural Mistake Coming Home to Roost?

The only reason to have an SMB server in-kernel is to speed things up. The only reason it gets speeded up, being in the kernel, is because that is where the networking is. If the networking was predominantly out in user space - like it is in FreeBSD, Windows, Mac, literally everything else - they wouldn't have to keep shoe-horning such things into the kernel.

The way this will end is with the Linux kernel being bloated and full of vulnerabilities, whilst network applications / servers not yet ported into it will remain emcumbered. If there were one thing to do to guarantee the future value and correctness of the kernel, it's getting rid of the networking to userland now, before it's too late (if it's not already).

[Crypto Monad]

Re: Age Old Architectural Mistake Coming Home to Roost?

> getting rid of the networking to userland now, before it's too late

It's been done - see VPP and DPDK.

But I don't know if anyone has plugged in any endpoint network apps, as opposed to just routing packets.

[Orv]

Re: Bootnote

You can do Time Machine backups to SMB shares -- I have it working for a few dozen computers, backing up to a FreeBSD system with ZFS storage. The settings that worked for me:

Global:

vfs objects = acl_xattr catia fruit streams_xattr

fruit:metadata = stream

fruit:model = MacSamba

fruit:posix_rename = yes

fruit:zero_file_id = yes

And then per share:

fruit:time machine = yes

Each share is restricted using "valid users" to a username unique to each machine, so they can't read each others' backups.

I take timed ZFS snapshots, so that a machine infected by ransomware can't encrypt all of its own backups.

You need to use refquotas to keep things under control, since Time Machine will keep adding backups until the disk is full, then delete the oldest ones. (If you use straight quotas it won't work because deleting files won't delete the snapshots, and thus will never free up any space for the client.)

I've successfully done Migration Assistant restores from this setup. It's slow, but within normal bounds for Time Machine.

[Androgynous Cupboard]

Re: Bootnote

I have a similar setup and yes it does work. If you're on ZFS, "fruit:resource = xattr" might be of interest - that's how we roll here. It's been a while, but I remember lots of "macOS droppings" all over my filesystem as a result of it trying to store resource forks in standalone files. Less of an issue these days I think, but still. Also see fruit:nfs_aces=no if you've got NFS access to the same folders

The "refquotas" is a great tip, thanks - I see it's specifically a fix if you're using ZFS snapshots, which to my shame I'm not. Noted for next time.

[Orv]

Re: Bootnote

Right, if you set "quota=300G", the dataset can't exceed 300 GB *including snapshots*. Using "refquota=300G" instead means snapshots don't count against the quota. Time Machine gets a little confused if it starts deleting old backups and doesn't see any new space appear. ;)

Good point on fruit:resource. I haven't added that because this server is strictly for Time Machine backups, so it just ends up with a bunch of sparsebundle files. I'm considering setting up another one to replace our macOS file server, and if I do I'll definitely check out that option.

[katrinab]

Re: Bootnote

My settings are

[timemachine]

comment = timemachine

path = /pool/timemachine

force group = "Domain Users"

directory mode = 0777

force directory mode = 0777

create mode = 0666

force create mode = 0666

vfs objects = zfsacl catia fruit streams_xattr

fruit:volume_uuid = 119e171f-1b88-4304-afd4-e378b90921e4

fruit:metadata = stream

fruit:model = MacSamba

fruit:posix_rename = yes

fruit:zero_file_id = yes

fruit:veto_appledouble = no

fruit:wipe_intentionally_left_blank_rfork = yes

fruit:delete_empty_adfiles = yes

fruit:time machine = yes

available = yes

read only = no

browsable = yes

public = yes

writable = yes

I also have avahi-daemon which provides the Apple Bonjour stuff that lets the Mac know of the Time Machine's existence.

[Orv]

Re: Bootnote

Ah, that's pretty cool. I'm in an academic environment with clients spanning a few different subnets, so I tend to avoid Bonjour. It works great for a home or small office setup where everyone is on the same subnet and VLAN, though.

[Liam Proven]

Re: Bootnote

[Author here]

> You can do Time Machine backups to SMB shares

Oh, yes indeed you can. I should have been clearer. I used AFP for several reasons:

• That's what I had on my old Raspberry Pi DIY server, now replaced with TrueNAS;

• I still had some quite old Macs in use, back in Prague;

• Nostalgia.

I could switch it, and while my current NAS still runs TrueNAS 12, in TrueNAS 13 AFP is deprecated, so I will have to switch at some point relatively soon.

[Kurgan]

Re: Bootnote

Wow, an easy setup (sarcasm alert!). Never seen so many quirks and workarounds.

[ptribble]

"OpenSolaris did the same back in 2007, and it's doing fin— Oh wait."

The in-kernel smb server is still present in illumos, and actively maintained.

The interesting part of that is not so much the SMB server part, but that the use of Windows SIDs is fully integrated into the OS and ZFS, so you can manage ownership and permissions for Windows users natively.

[that one in the corner]

Magical rusty thinking

> Unless this is formally proven or rewritten in a safer language...

(With the corollary that we all know there is only candidate for that "safer language" in the Linux kernel...)

Because, of course, the two are equivalent: if you write in Rust it is as good as a formal proof. Not.

Even if this guy was being hyperbolic[1] it is a bad idea to bandy around such an idea: there exist people who would love to take such an implied equivalence seriously. Without considering that, for example, memory errors of the sort Rust can deal with would be nothing compared to, say, an overly-privileged SMB server forgetting to honour any access rights[2].

Now, if there was a push from a section of the community to get code into the kernel that was written in a language amenable to formal proofs, and the accompanying proofs for each module, we could really start making some progress with a trustworthy OS[3][4]

[1] ref the mention of being paid in gold - which is a weird request but if he thinks the hassle of liquidating that is worth the hassle, each to their own

[2] no, not trying to say that KSMBD has this flaw, it is just an example of a logic/design/coding flaw that can exist without any bad memory accesses.

[3] you may say I'm a dreamer, and I'm probably the only one...

[4] btw, I'm nowhere near clever enough to create a proof of any program, let alone one worth running (I did the reading back in Uni, however...). Shameful, I know.

[drankinatty]

Re: Magical rusty thinking

The only reason rust exists is to save crappy programmers from themselves. Yes, if you never learned to count, C can provide a challenge in managing memory. But for anyone that can count and do any type of sane bounds checking, the magic of rust quickly evaporates as if covered with Naval Jelly...

[Lee D]

Nothing says "kernel-level compromise" quite like putting an antique, backwards-compatible user-facing network service into the kernel for performance reasons.

Especially when for decades it's been a user-level application with numerous protocol security problems but otherwise without major issue in terms of operation or performance.

Did we not learn from IIS?

[abend0c4]

Mac OS X has gradually been made more and more reliant on SMB

Since the demise of Apple's server products it's pretty much given that SMB is going to dominate in practice, it's not really a technical issue.

Having kernel support for SMB isn't going to signficantly influence protocol choices on Linux systems - it's principally determined by the environment of other machines in which they're operating. NFS may have been latterly adopted as "Unix's own native file-sharing protocol", but it only really emerged to support Sun's workstation model. And of course NFSv4 is so significantly different to previous versions that it perhaps should be considered entirely separately.

But if yoiu're worried about the unnecessarily large attack surface caused by SMB services in the kernel, presumably you ought to be at least as worried about NFS - the usual default these days is for support for multiple versions to be in kernel space rather than in user space. The righteous indignation that greeted Microsoft's decision to put chunks of its graphics code into the kernel for performance reasons doesn't seem to have been replicated in this case.

There does seem to be a particular problem with file servers. It's not simply performance, VFS doesn't seem to be ideal for handling remote operations. And of course it can be tricky mapping identities and permissions. However, when there's an entire class of formerly userland functionality that is being dumped into kernel space, it sounds like it deserves some attention.

[Androgynous Cow Herd]

" and will integrate with Samba in the future."

So - We will install "SUCKS" at a later date?

Because SAMBA continues to suck.