SP v4 alpha2 sessions ?

[Jarno Huuskonen]

Hi,

On Fri, 2026-09-18 at 10:19 -0400, Scott Cantor via users wrote:
> 
> > I think there's TOCTOU race in
> > session/impl/FilesystemSessionCache.cpp:L211-220 and L422-448
> > session file is created with open O_CREAT | O_EXCL and then fd is
> > closed and then reopended with ofstream os(path);
> 
> There shouldn't be unless open() doesn't in fact create the file, but
> it's possible it doesn't, I'll have to add a unit test for that in
> isolation to check. The intent is that once the file exists, that
> isolates that sequence of code because anything else will be gated by
> the O_CREAT|O_EXCL flags and fail trying to create a duplicate.
> Nothing else is meant to know about that session key yet, so it can't
> be in use in another thread in a legitimate way.
> 

O_CREAT|O_EXCL should work (refuse to create file if it already
exists).

What I had in mind was default apache + php-fpm setup where php runs as
same user as apache (php has access to cacheDirectory). (There are
probably university servers where there are not so trusted php code
running).

I didn't think this fully, why try to win complicated race condition
between close(f) and ofstream open when php has full access to
directory (create session files etc.).
php (and other cgi) really needs to run as different user than apache
and/or use systemd sandboxing to prevent access to cacheDirectory.
(systemd InaccessiblePaths=your_cache_dir_here).

> > Using (gnu extension) something like:
> 
> I can't use gnu extensions. I'll see if there's any other way to
> adopt the handle, but it shouldn't be necessary unless open doesn't
> do what it's meant to. If I have to I can write something to the file
> to ensure it's actually created in while still open.
> 

I think boost has boost::iostreams::file_descriptor_sink/source to use
open fd. But don't think it's needed if attacker/bad script has write
access to cacheDirectory then symlinks are not main concern.

> > and removing close(f) after open() could fix the open/use race.
> 
> It's not a race as long as the file actually exists after open() or
> unless the flags don't do what they are documented to do and prevent
> a second call to open the same filename. The name itself is the
> mutex, it's trying to reserve the name.
> 
> All of this assumes atomic open calls. If they eventually prove not
> be atomic, I will abandon the pretense that the file system is a
> viable session store.

There's a small window:
f=open(O_CREAT|O_EXCL...);
close(f);
// small window between close and ofstream where another process can
remove file / symlink it to another file.
ofstream os(path);

> To be clear...I wouldn't use the filesystem in a million years. It
> isn't going to be the default once this ships, I'll flip it to
> storage or to a cookie-based mechanism as a default. The risks are
> too difficult to mitigate.
> 

Is the cookie based mechanism going to use memory as cache and call to
hub only when needed ?

-Jarno


-- 
Jarno Huuskonen