rsync 3.5.0 released [LWN.net]

Version 3.5.0 of rsync has been released with a huge number of security fixes:

This release fixes 33 security issues found during a focused audit of rsync's path handling and daemon protocol, a companion daemon-protocol fuzzing pass, and reports from external researchers -⁠-⁠ plus several robustness hardenings. CVE IDs were assigned by VulnCheck (CNA); the precise "introduced in" version ranges accompany each advisory, and many are much narrower than "everything before 3.5.0". Every fix ships with a regression test in the test suite that fails on the unfixed tree.

to post comments

An annoying bug that I've hit is fixed, I believe

Posted Aug 13, 2026 14:22 UTC (Thu) by dskoll (subscriber, #1630) [Link] (1 responses)

I think (hope) that 3.5.0 also fixes rsync hangs with some specific files, using 100% of 1 CPU core but without disk nor network activity.

An annoying bug that I've hit is fixed, I believe

Posted Aug 14, 2026 11:29 UTC (Fri) by honschu (subscriber, #61008) [Link]

Yes, and it even got a CVE assigned to it. Performance improvements are still ongoing.

Still paying for symlinks.

Posted Aug 13, 2026 19:06 UTC (Thu) by jra (subscriber, #55261) [Link] (41 responses)

Almost all of these are symlink races. If even tridge can't write symlink-safe code, what hope do regular engineers have of avoiding these issues.

We *must* revisit the symlink disaster (IMHO).

Still paying for symlinks.

Posted Aug 13, 2026 20:50 UTC (Thu) by intelfx (subscriber, #130118) [Link] (23 responses)

We must revisit the symlink disaster (IMHO).

To me as a mere mortal, symlinks are extremely useful, and I tend to use them extensively in course of normal system administration tasks (on personal and non-personal machines alike), or to work around unwanted behavior of certain software (whose volume is much greater that I could ever hope to fix, if the answer is "well then fix your software").

I'm not sure what I would replace their usage with, should the "symlink disaster" be revisited.

Still paying for symlinks.

Posted Aug 14, 2026 2:22 UTC (Fri) by jra (subscriber, #55261) [Link] (21 responses)

A simple fix to remove 99% of all race conditions and still allow you to administer your machine would be to have a mount option that restricted symlink creation to root accounts only.

Still paying for symlinks.

Posted Aug 14, 2026 3:30 UTC (Fri) by intelfx (subscriber, #130118) [Link] (20 responses)

A simple fix to remove 99% of all race conditions and still allow you to administer your machine would be to have a mount option that restricted symlink creation to root accounts only.

But that's not a good fix. I wouldn't want to have to reach for root each time I want to symlink something in my $HOME, or forward root into build containers (I wouldn't want to do this anyway, that's kinda the point of build containers) each time a build script needs to use symlinks to circumvent some kind of Go or Rust madness, etc.

Still paying for symlinks.

Posted Aug 14, 2026 4:27 UTC (Fri) by jra (subscriber, #55261) [Link] (17 responses)

Well your only options are a bit of inconvenience for you vs. all software accessing the file system suffering from incurable and undiscovered symlink races.

I know which I would choose...

BTW, this one area where Windows gets it right. Symlinks are only creatable by Administrator by default there.

Still paying for symlinks.

Posted Aug 14, 2026 8:29 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

Well, perhaps software should just avoid doing symlink parsing across privilege boundaries.

Still paying for symlinks.

Posted Aug 14, 2026 11:13 UTC (Fri) by pizza (subscriber, #46) [Link]

> I know which I would choose...

Me too -- I'll choose the current status quo every time.

I make use of non-administrative symlinks literally dozens of times a day. It *vastly* simplifies overall system (and individual software application) complexity.

Still paying for symlinks.

Posted Aug 17, 2026 8:31 UTC (Mon) by taladar (subscriber, #68407) [Link] (14 responses)

Sorry, the "destroy everyone's use cases for an imagined security issue" crowd already got Wayland this century so destroying symlinks will have to wait for the next one.

Still paying for symlinks.

Posted Aug 17, 2026 11:15 UTC (Mon) by marcH (subscriber, #57642) [Link] (13 responses)

> Sorry, the "destroy everyone's use cases for an imagined security issue" crowd...

Based on your analysis, did rsync really fixed dozens of "imagined" security issues?

PS: while the "features vs security" tension is eternal, I never heard about such a "crowd". Most people seem not religious about it. Even on antisocial media this topic seems generally quite tame.

> already got Wayland this century

I believe the main drives behind Wayland were simplification (which always helps with security) and performance. Off-topic anyway.

> so destroying symlinks will have to wait for...

Agreed: this one would be really hard to take back, breaking way too many things.

Still paying for symlinks.

Posted Aug 25, 2026 14:18 UTC (Tue) by turistu (guest, #164830) [Link] (12 responses)

I believe the main drives behind Wayland were simplification (which always helps with security) and performance. Off-topic anyway.

What simplification? With X11, you could write a fully fledged window manager (which did everything you wanted) in ~1500 lines of code, with no dependencies beyond xlib. And you could even get rid of the xlib, and just pack/unpack the X protocol messages by hand (which would make it even smaller).

With wayland, a window manager has to basically implement the entire X11 server itself.

OK, you're supposed to link in some stupid library to do the heavy lifting. How does loading a huge, complicated library (that you have very little hope of ever understanding in depth) in your address space (with no clear barrier between your code and their code) "help with security"?

Still paying for symlinks.

Posted Aug 25, 2026 14:32 UTC (Tue) by hmh (subscriber, #3838) [Link] (10 responses)

Isolation between wayland applications is much better than with X11 in any practical scenario. This is usually the kind of security boundary being talked about when people compare X11 to wayland in a security sense.

Still paying for symlinks.

Posted Aug 26, 2026 7:49 UTC (Wed) by taladar (subscriber, #68407) [Link] (9 responses)

And that is exactly the kind of imagined security issue that just didn't happen in practice. Sure, something could capture your key strokes but compared to every other security issue, how often did we actually see this? Did it really require killing off this many legitimate applications that required these security boundaries to be more permeable?

Still paying for symlinks.

Posted Aug 26, 2026 11:07 UTC (Wed) by marcH (subscriber, #57642) [Link] (8 responses)

Security bugs are bugs but with a fundamental difference: the question "How often does it happen in practice?" does not make sense for them. A bit like "I don't mind leaving the window open cause the majority of thieves prefer the door"

Maybe you meant: "I don't mind leaving that window open because it is inside some secure perimeter that I trust. I don't need defense in depth here". That is a quote different statement.

Still paying for symlinks.

Posted Aug 26, 2026 16:26 UTC (Wed) by mb (subscriber, #50428) [Link] (7 responses)

Well, the thing is that if all the applications running are trusted, this scenario isn't an actual security problem at all. It's a feature, not a bug, in this case.

Yes, most applications don't need to capture all keystrokes and don't need full control of their window. But some applications do. It's a mistake to not let them do that (e.g. after special case whitelisting or whatever). Wayland is breaking real world use cases for the sake of fixing a security issue that may not even be a security issue in this particular context and instance.

Let the user set the policy whether keystroke capturing is allowed for certain apps. It's a mistake to kill this feature.

Still paying for symlinks.

Posted Aug 26, 2026 18:34 UTC (Wed) by pizza (subscriber, #46) [Link] (6 responses)

> Well, the thing is that if all the applications running are trusted

That's a mighty big IF that is only rarely true in practice.

Still paying for symlinks.

Posted Aug 26, 2026 19:52 UTC (Wed) by mb (subscriber, #50428) [Link] (5 responses)

The biggest problem of the Wayland fanboys is the "your use case does not matter and has a big IF" attitude.

No, this is not rare. Trusting all apps is the normal case on a Linux desktop system. If you start an untrusted app you have to consider all your /home data to be read and exfiltrated by an attacking app. Reading the keyboard is the least of the problems when running untrusted apps.

I'm not against restricting keyboard reading and such stuff, because it is a thing that most apps do not need. I'm just saying it's a mistake to remove this feature for all apps and just ignore people complaining.

Still paying for symlinks.

Posted Aug 26, 2026 20:12 UTC (Wed) by pizza (subscriber, #46) [Link] (2 responses)

> Reading the keyboard is the least of the problems when running untrusted apps.

If /home is compromised, they don't get my login credentials to anything else.

If my keyboard/input stream is compromised, they can get into _everything_.

This sort of thing is why *every* mainstream operating system doesn't grant applications free access to every other application's input.

> I'm not against restricting keyboard reading and such stuff, because it is a thing that most apps do not need. I'm just saying it's a mistake to remove this feature for all apps and just ignore people complaining.

Alternatively -- it's a mistake to freely grant that capability to all applications when only a few need it.

And that's the approach Wayland has taken -- no general capability; instead it has to be explicitly requested and granted where necessary.

Still paying for symlinks.

Posted Aug 26, 2026 20:25 UTC (Wed) by mb (subscriber, #50428) [Link] (1 responses)

> If /home is compromised, they don't get my login credentials to anything else.

That is not true at all.
Access to /home means arbitrary code execution and arbitrary faking of installed applications via .bashrc, manipulation of PATH and many more.

>And that's the approach Wayland has taken -- no general capability; instead it has to be explicitly requested and granted where necessary.

Ok, well. If that is actually true by now, then I'll stop complaining.
That's exactly what I want. Stop pretending that use cases do not exist and let users configure it.

Still paying for symlinks.

Posted Aug 28, 2026 18:01 UTC (Fri) by raven667 (subscriber, #5198) [Link]

> Access to /home means arbitrary code execution and arbitrary faking of installed applications via .bashrc, manipulation of PATH and many more.

Allowing apps arbitrary access to $HOME is itself a security problem (because all apps are not trustworthy and some can be compromised, the average app doesn't provide a solid security boundary) which is why sandboxing (like Flatpak) exists. Access to files should be restricted to just the project and settings directories private to the app and specific files the user chooses interactively through an XDG Portal. Limiting the blast radius of a malicious or compromised app making the whole desktop safer to use, rather than just giving up and acting like there is no possibility of security. I mean we could chmod -R 777 / on a single-user desktop and call it a day, but I don't think that makes a robust and reliable system.

Still paying for symlinks.

Posted Aug 26, 2026 21:45 UTC (Wed) by mbunkus (subscriber, #87248) [Link] (1 responses)

I think you & me have different understanding of the word "trust". The one app I am always suspicious of is the web browser, because its primary job is arbitrary code execution of untrusted third-party code nowadays. Sure, I "trust" it enough that I do run it & have JavaScript enabled (with certain limitations imposed by plugins), but I'm still glad I have to approve each and every time the web browser wants to access my microphone, my camera or screen share anything — and that this type of access control is imposed upon the browser from an external entity, not depending on the browser's goodwill to ask you if you want to do that (or not).

Still paying for symlinks.

Posted Aug 26, 2026 22:01 UTC (Wed) by marcH (subscriber, #57642) [Link]

> that this type of access control is imposed upon the browser from an external entity, not depending on the browser's goodwill to ask you if you want to do that (or not).

Everyone's usage is different but I would bet that for many people, browser exploitation is about as bad as /home or keyboard exploitation nowadays... because as you just described, the browser is basically the "Internet Operating System" running in some sort of container isolation:

> The one app I am always suspicious of is the web browser, because its primary job is arbitrary code execution of untrusted third-party code nowadays.

This isolation offers some protection, but for the many people who "live in the cloud" then pretty much everything is located on one side of that of that isolation anyway, I mean there isn't a lot left to protect on the other side.

Anyway I agree that "console access" (keyboard and screen) is among the most critical things to protect. There is such a thing as too fine-grained permissions and "permission fatigue" but that one can really not be "all or nothing", it's too important.

Still paying for symlinks.

Posted Aug 25, 2026 15:39 UTC (Tue) by intelfx (subscriber, #130118) [Link]

With X11, you could write a fully fledged window manager (which did everything you wanted) in ~1500 lines of code, with no dependencies beyond xlib

...and the rest of the X11 server over the wire, which is also a dependency. Something does not stop being a dependency simply because you do not link it into your process.

With wayland, a window manager has to basically implement the entire X11 server itself.

You absolutely can write a Wayland compositor in a comparable amount of lines, if you use a library like wlroots.

The only difference is that in X11, the window manager, the compositor, and the ~~crappy IPC~~ X11 server are all distinct processes, whereas in Wayland those will have to in the same process. This does not say anything about which protocol is "simpler".

Still paying for symlinks.

Posted Aug 25, 2026 14:03 UTC (Tue) by turistu (guest, #164830) [Link] (1 responses)

You could do with bind mounts everything you can do with symlinks, if there was some robust form of persistent namespaces (not a script to recreate them from configuration files, or similar horrors)

Still paying for symlinks.

Posted Aug 26, 2026 7:43 UTC (Wed) by taladar (subscriber, #68407) [Link]

Unfortunately that "everything" includes a lot of the TOCTOU issues from name-based accesses.

Still paying for symlinks.

Posted Aug 14, 2026 17:22 UTC (Fri) by wtarreau (subscriber, #51152) [Link]

They're present everywhere because they solve so many issues, allowing to unify mount points and making them appear as if they had been there forever. It's been one of the most powerful features of unix-like systems compared to what we had in DOS/Windows era that made anyone switching to Linux suddenly feel a huge flexibility (along with multi-tasking of course).

Yes they cause problems but these problems are almost nothing for users compared to the everyday benefits. And requiring that only root would create them would just mean to add everyone to sudoers, making things even worse.

Still paying for symlinks.

Posted Aug 13, 2026 22:47 UTC (Thu) by gerdesj (subscriber, #5446) [Link] (1 responses)

Would you mind spelling out or pointing (lol) us civilians at some sort of commentary of this "disaster"?

Still paying for symlinks.

Posted Aug 13, 2026 23:29 UTC (Thu) by corbet (editor, #1) [Link]

See this article for details on Jeremy's objections to symbolic links.

Still paying for symlinks.

Posted Aug 14, 2026 8:00 UTC (Fri) by renox (guest, #23785) [Link] (2 responses)

> We *must* revisit the symlink disaster (IMHO).

Symlinks won't go anywhere because
1) pure hierarchical FS sucks.
2) lots of software doesn't follow XDG guidelines: at work my /home is small so I have to use symlinks to "redirect" applications huge files to another partition.

Still paying for symlinks.

Posted Aug 14, 2026 20:42 UTC (Fri) by NYKevin (subscriber, #129325) [Link] (1 responses)

3) Entire distros use symlinks as part of their normal operation, and will flatly veto any system-wide or mount-wide config knobs like MS_NOSYMFOLLOW. For example, Debian has /etc/alternatives, other distros may have similar mechanisms, etc.

Current user or root?

Posted Aug 15, 2026 5:25 UTC (Sat) by gmatht (subscriber, #58961) [Link]

What about MS_NOSYMFOLLOW... unless symlink owned by current user or root? That would seem to capture most of the use of symlinks while avoiding most of the cross-boundary security confusion.

Still paying for symlinks.

Posted Aug 15, 2026 16:50 UTC (Sat) by fwiesweg (guest, #116364) [Link] (5 responses)

There is also the use case of atomically replacing a whole directory, which can currently only be implemented using a symlink to the new directory that is mv'd over the symlink to the old one. I use it extensively for zero-downtime deployments in /var/www/html, and it be really sad to see it go.

I'd definitely be in for root-only symlinks, though, that sounds like a very reasonable compromise, especially if I can switch it on/off at runtime. It also looks much more realistic than all of those millions of lines of code running on my machines correctly implementing path traversal.

Still paying for symlinks.

Posted Aug 15, 2026 18:26 UTC (Sat) by intelfx (subscriber, #130118) [Link] (4 responses)

There is also the use case of atomically replacing a whole directory, which can currently only be implemented using a symlink <..>

I don't think so; renameat2(RENAME_EXCHANGE) exists and does what it says on the tin.

That is not to say, of course, that symlinks are indispensable for a number of other tasks across privileged and unprivileged contexts alike.

Still paying for symlinks.

Posted Aug 15, 2026 18:27 UTC (Sat) by intelfx (subscriber, #130118) [Link]

That is not to say, of course, that symlinks are indispensable

s/are/aren't/, of course

Still paying for symlinks.

Posted Aug 16, 2026 14:09 UTC (Sun) by kleptog (subscriber, #1183) [Link] (2 responses)

> I don't think so; renameat2(RENAME_EXCHANGE) exists and does what it says on the tin.

Which I'd never heard of before. And apparently can be accessed from the commandline as "exch" which (on Debian at least) is in the util-linux-extra package.

Still paying for symlinks.

Posted Aug 16, 2026 20:35 UTC (Sun) by intelfx (subscriber, #130118) [Link] (1 responses)

And apparently can be accessed from the commandline as "exch" which (on Debian at least) is in the util-linux-extra package.

mv --exchange (plain old coreutils) exists, too; although I don’t know if it is old enough to wind up in at least one Debian stable.

Still paying for symlinks.

Posted Aug 16, 2026 20:53 UTC (Sun) by gioele (subscriber, #61675) [Link]

> `mv --exchange` (plain old coreutils) exists, too; although I don’t know if it is old enough to wind up in at least one Debian stable.

It's available since Debian 13 (trixie / stable).

Still paying for symlinks.

Posted Aug 15, 2026 22:22 UTC (Sat) by ceplm (subscriber, #41334) [Link] (5 responses)

Well, until I could make a hard link for directories, I won’t budge. I just have not been able to use my system without symlinks for the last twenty five years, and I don’t see it changing.

Still paying for symlinks.

Posted Aug 20, 2026 0:53 UTC (Thu) by willy (subscriber, #9762) [Link] (3 responses)

Hard links for directories are Really Really Bad. What should "cd .." do in such a monster? (There are other reasons too, but they might be fixable)

Still paying for symlinks.

Posted Aug 20, 2026 6:43 UTC (Thu) by neilbrown (subscriber, #359) [Link] (1 responses)

> Hard links for directories are Really Really Bad. What should "cd .." do in such a monster?

Easy peasy. David Korn (of ksh fame) solved this years ago.

https://groups.google.com/g/comp.unix.wizards/c/rkPBbdTEL...

Instead of storing a vfsmount/dentry pair as the cwd for each process, store a textual path.
Then handle ".." by simply editing the path, removing the last component.

(and make sure no-one ever renames any directory, as that could mess up some paths).

Still paying for symlinks.

Posted Aug 20, 2026 7:14 UTC (Thu) by mb (subscriber, #50428) [Link]

I'm not so sure about that. What if there is no full cwd path, because the tree has been walked with *at()? Do you want to store a possibly infinitely growing dynamically stacked path (each at-walk adds a new relative component)?

Still paying for symlinks.

Posted Aug 20, 2026 7:15 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

Isn't a useful cd definitionally a shell builtin, and so "cd .." can just be handled using whatever policy it wants based on pwd? In bash mkdir -p /tmp/a/b; ln -sf /tmp/a/b /tmp/c; cd /tmp/c; cd .. leaves you in /tmp, not /tmp/a. The thing that seems immediately tedious is being able to create cyclical directory structures you can unlink from the rest of the filesystem? But I don't even play a VFS developer on TV so I suspect I'm missing something here.

Still paying for symlinks.

Posted Sep 2, 2026 21:28 UTC (Wed) by JanC_ (subscriber, #34940) [Link]

NTFS has support for that…