@joshbressers I can see your point, but I don't agree with it. The ".." path element (meaning parent directory) is useful, not just for "cd ..". I agree that it should be hard to allow users/attackers to introduce it to paths. Absolute paths are too cumbersome, and not an acceptable solution.

What I would like is types for path that don't have ".." and paths that may have them, and safe conversions from the latter to the former.

@joshbressers I use .. and relative paths in a static site generator, for example, so that the output is not tied a specific path prefix or URL. This is way too handy for me to give up. Sorry.

@joshbressers Sooo https://gitlab.com/mjg59/linux/-/commit/13cd6ec5e0e99124dd730156a4d921b20f192e2d

@joshbressers I have *no* idea how much it breaks - it wouldn't surprise me if a bunch of libraries do stuff here

@mjg59 @joshbressers If it is not inherited accross exec, it should be doable (but may not help much). Inheriting it across exec will make it dangerous.

@joshbressers not sure how well known this is or how many #Linux developers casually read through pre-v5 #UNIX sources, but here's a bit of (possibly slightly uninformed) trivia:

".." is a relic from time before path names.

There was a time when UNIX had a directories, but no path names. Following the ".." link was therefore the only way to navigate the hierarchy.

[1/2]

@joshbressers Without path names, it was impossible to reach files outside your working directory. You'd need to link them into your directory first.

Setting up a new user involved linking all the devices a user would need into their home directory. That's where ".." comes useful:

# mkdir josh
# cd dev
# ln tty ..
# cd ..
# ln tty josh
# unlink tty
#
# npm install 💩

[2/2]

@mjg59 @joshbressers I had the exact same idea!

@pavel @joshbressers @mjg59 What's the problem with inheriting across exec? I mean, the prctl is opt-in, so any application that is hardened this way can remove it before exec()'ing something that wasn't hardened. What do I miss?

@joshbressers On the one hand yes (we wouldn’t have beauties like https://github.com/python/cpython/issues/73974, CVE-2007-4559; I spent with it more time than I wished to), on the other hand with the same logic we should eliminate any links (symlinks or hard links). We don’t use absolute paths all the time, because we don’t want to use absolute paths all the time, it is sometimes just useful not to.

@ptesarik @joshbressers @mjg59 setuid. :-)

@joshbressers @lkundrak
until proven otherwise, any long-lived software feature should be assumed to have evolved in a peculiar historical context, quite different from recent experience, and no longer widely known.

@llewelly @joshbressers oh yeah, and then someone wanted to make /bin/ls not clutter its output by including the "." and ".." entries. took a shortcut and skipped files where name[0] == '.'

lo and behold

.dotfiles

$ ls -d ~/.* |wc -l
197

/me weeps silently in the corner

@joshbressers working from sketchy memory here, but wasn't this explicitly not part of the java original specification precisely because of security concerns? I seem to remember it was a fairly hot button issue and one argument that it would never 'work' as a general use thing, back when Sun was pushing it fairly heavily. I should really take some time and look into that...

@joshbressers honestly imo .. in paths should be handled by path libs that explicitly allow it, because it is useful sometimes, but you really shouldn't use it unless it makes sense to

a user specifying where to save smth ? sure. a path to a critical component ? nah

@joshbressers STOP uuSImg Comphurter
comoter is unsafe

@joshbressers It’s probably easier to eliminate path traversal than to rewrite all extant C code, but that doesn’t mean it’d be *easy*. And I’m not sure it’s the right solution. Relative addressing within a file system is incredibly useful. Surely the design flaw is that applications are not by default sandboxed?

@joshbressers 100% agree there given that the nasty security bugs I've had to fix were path traversal ones and those are very trivial to exploit.

Which often makes me feel like it's something like a type safety problem (like filename vs. path, which have different allowed characters), or a greater language design problem as in a way it's getting path evaluated in unknown locations of your programs (or part of kernel, so OS design) rather than at precise ones where you explicitly choose to and so could then use things like static analysis.

@joshbressers and the exhortation to “stop writing C” usually means stop writing *new* C code, which is a much simpler task.

@joshbressers surprisingly most path traversal bugs I’ve run into recently are in the SDKs and not the OS functions (Go AWS SDK for S3 resolves .. even though S3 doesn’t, etc)

@utterfiction @joshbressers on plan 9, programs like web servers do bind the to-sandbox directory to / within the program. Then the relative paths are the absolute paths automatically, and .. can't break out of the sandbox path. It's actually quite easy to do that if you don't need access to files outside the sandbox directory (you can still find a way around that within your program, but that depends on the program flow)