llpath.txt

2 files changed, 94 insertions, 0 deletions

diff --git a/index.html b/index.html
index b444873..9c1a17f 100644
--- a/index.html
+++ b/index.html
@@ -43,8 +43,10 @@
 </ul>
 
 <h2 id="articles">Personal Articles</h2>
+<p>Some of these are just stubs or quick notes.</p>
 <p>See also: <a href="https://git.runxiyu.org/runxiyu/current/philo.git/plain">Documents archive</a></p>
 <ul>
+	<li><a href="llpath.txt">An IRC conversation about "using linked lists to represent paths"</a></li>
 	<li><a href="https://git.runxiyu.org/runxiyu/current/philo.git/plain/identity-over-time-jl.pdf">In what sense are you the same person today that you were when you were ten?</a></li>
 	<li><a href="https://git.runxiyu.org/runxiyu/current/philo.git/plain/notes/affirmative-action/affirmative-action-discussion-brief.pdf?id=8065ac64fd09467c0c4e98625ace35d009b7c589">Affirmative Action (Students for Fair Admissions v. Harvard/UNC) discussion brief</a> (<a href="./affirmative-action.txt">original</a>)</li>
 	<li><a href="./journey-overcoming-rationalism.html">A journey to overcome rationalism?</a></li>
diff --git a/llpath.txt b/llpath.txt
new file mode 100644
index 0000000..e276735
--- /dev/null
+++ b/llpath.txt
@@ -0,0 +1,92 @@
+2024-05-28 20:26:26	~runxiyu_	hax: also, imagine a world where paths are linked lists rather than strings
+2024-05-28 20:27:52	&hax	linked lists nah just use dir reading all the way
+2024-05-28 20:28:07	~runxiyu_	hax: ?
+2024-05-28 20:28:48	&hax	next = opendir(this);
+2024-05-28 20:29:06	&hax	*opendir(this, name)
+2024-05-28 20:29:28	~runxiyu_	hax: no
+2024-05-28 20:29:47	&hax	:D
+2024-05-28 20:29:52	~runxiyu_	hax: Honestly though I think linked-list (or "slices" or whatever it's called nowadays) would be pretty good at preventing directory traversal attacks?
+2024-05-28 20:29:58	~runxiyu_	i mean
+2024-05-28 20:30:04	~runxiyu_	why interpret strings?
+2024-05-28 20:30:43	&hax	not really, because directory path manipulation relies on hardlinks/symlinks in the path
+2024-05-28 20:30:58	&hax	in that sense I mean
+2024-05-28 20:30:58	~runxiyu_	hax: i mean, in an imaginary new system
+2024-05-28 20:31:16	&hax	problem: .. is actually useful
+2024-05-28 20:31:17	~runxiyu_	where symlinks don't exist. symlinks confuse the heck out of me
+2024-05-28 20:31:38	&hax	symlinks are weird yes
+2024-05-28 20:31:46	&hax	but still hardlink of .. and .
+2024-05-28 20:31:56	&f_	both "-1"'s are supposed to be EOF instead..
+2024-05-28 20:32:22	~runxiyu_	hax: ?????
+2024-05-28 20:33:03	~runxiyu_	I'm not sure how hardlinking directories work
+2024-05-28 20:33:07	~runxiyu_	I don't think that's possible
+2024-05-28 20:33:14	&hax	runxiyu_: it escapes via say "blahblah/whatever/../../../../../etc/passwd" or the likes
+2024-05-28 20:33:15	~runxiyu_	how do the inodes even record those
+2024-05-28 20:33:30	~runxiyu_	hax: oh, so it's not a hardlink issue, it's a .. issue
+2024-05-28 20:33:32	&hax	the problem with fixing that is you still need a notation of "go back a dir"
+2024-05-28 20:33:49	~runxiyu_	actually true
+2024-05-28 20:33:50	&hax	well links that go to a different dir in a different path contain the same problem
+2024-05-28 20:34:02	~runxiyu_	hax: .. = pop(pwd())
+2024-05-28 20:34:25	&hax	hmmmmmmm
+2024-05-28 20:34:45	~runxiyu_	well ok it's not fair to assume that everything is written in a "proper" programming language
+2024-05-28 20:34:49	&hax	what if someone creates a literal `..`
+2024-05-28 20:34:52	~runxiyu_	but sane shells should have sane vector manipulation
+2024-05-28 20:35:03	~runxiyu_	hax: sounds fine to me (again in an imaginary new system)
+2024-05-28 20:35:21	&hax	well, now you can only access it via "untrusted" input paths
+2024-05-28 20:35:28	&hax	because "trusted" ones get evaluated
+2024-05-28 20:35:32	~runxiyu_	?
+2024-05-28 20:35:48	&hax	if you impliment `.. = pop(pwd());` in the shell
+2024-05-28 20:35:56	~runxiyu_	hax: I mean firstly I'm hypothesizing a system where all paths are linked lists / arrays / vectors / whatever, and "." and ".." mean nothing
+2024-05-28 20:36:15	~runxiyu_	hax: oh, I meant, instead of using "..", use "$(pop $(pwd))"
+2024-05-28 20:36:20	&hax	you need a way to designate "back", in a human-usable fashion
+2024-05-28 20:36:33	&hax	and pop pwd isn't really good since there's many other contexts
+2024-05-28 20:36:34	~runxiyu_	hax: that sounds like the task of the human-used program, not the operating system's structure
+2024-05-28 20:36:44	~runxiyu_	filesystem's
+2024-05-28 20:36:48	~runxiyu_	i mean
+2024-05-28 20:36:48	&hax	yes, I mean conflicts are an issue
+2024-05-28 20:36:54	~runxiyu_	well true
+2024-05-28 20:37:06	~runxiyu_	but eeehhhhh
+2024-05-28 20:37:37	&hax	I don't require that the OS uses even strings at all, but you still need human-usable ways of getting back a dir and such
+2024-05-28 20:37:37	~runxiyu_	"conflicts with how shells might represent them" doesn't sound like a good reason to clutter up the operating system's path representation with string interpretation
+2024-05-28 20:37:47	~runxiyu_	mhm
+2024-05-28 20:38:23	&hax	"shells have no good way for humans to interact" does sound like a good reason to clutter up the operating system's path representation with a few exceptions or such
+2024-05-28 20:38:58	&hax	main point being, changing the representation won't fix the exploits
+2024-05-28 20:39:07	&hax	unless you also make it less useful
+2024-05-28 20:39:13	~runxiyu_	hax: well, modern shells also interpret "~" specially
+2024-05-28 20:39:29	~runxiyu_	and that seems... really useful
+2024-05-28 20:39:33	&hax	yes
+2024-05-28 20:39:45	~runxiyu_	"why not use $HOME?" -> "why not use $(pop $(pwd))"
+2024-05-28 20:40:05	&hax	because /~/foo/bar isn't //home/user/foo/bar
+2024-05-28 20:40:21	&hax	and you can't sanely require escaping ..
+2024-05-28 20:40:52	~runxiyu_	hax: is there a time you actually need to specify /home/me/../another_user in a shell?
+2024-05-28 20:41:17	~runxiyu_	i feel like .. is similarly not really useful other than in the beginning of a path
+2024-05-28 20:41:24	&hax	runxiyu_: there are times where /path/to/something/../ is often used
+2024-05-28 20:41:40	~runxiyu_	by scripts or by humans
+2024-05-28 20:41:48	&hax	probably more the latter
+2024-05-28 20:41:55	~runxiyu_	huh?
+2024-05-28 20:42:00	&hax	er, former*
+2024-05-28 20:42:17	~runxiyu_	sounds like a case for $(pop $(pwd))
+2024-05-28 20:42:33	~runxiyu_	though perhaps humans would use ../../../testing/thing
+2024-05-28 20:42:45	&hax	yes that I do use often
+2024-05-28 20:43:05	~runxiyu_	but that's beginning-of-relative-ish-path
+2024-05-28 20:43:28	&hax	but how do you access ../../literaldotdot/testing/thing
+2024-05-28 20:43:30	~runxiyu_	hax: can i log this conversation and put it somewhere public
+2024-05-28 20:43:39	~runxiyu_	hax: hmmmmmmm
+2024-05-28 20:43:52	~runxiyu_	hax: good point
+2024-05-28 20:44:29	&hax	and sure
+2024-05-28 20:44:38	~runxiyu_	 /save
+2024-05-28 20:45:44	&hax	anyways, linked lists is fine, but trying to `not have ..` for `security purposes` won't really help anything
+2024-05-28 20:46:30	~runxiyu_	mainly because of human shells though
+2024-05-28 20:46:31	~runxiyu_	idk
+2024-05-28 20:46:44	~runxiyu_	and i mean, why have special names at all?
+2024-05-28 20:47:17	&hax	. and .. aren't special names, they're just a reference in the fs to the dir before them (as far as I know)
+2024-05-28 20:47:44	&hax	probably not written on disk ofc, but in the kernel's mapping or whatever it's called of it
+2024-05-28 20:48:28	&hax	*to the dir and the dir before it
+2024-05-28 20:48:50	~runxiyu	well if applications tell kernel to "check the path '..'" and the kernel sees that and treats it specially
+2024-05-28 20:48:58	&hax	does it
+2024-05-28 20:49:10	~runxiyu	if it's "the kernel's mapping"?
+2024-05-28 20:49:21	~runxiyu	.. then in the perspective of anything above ring 0, it's essentially a special name
+2024-05-28 20:49:22	&hax	I mean as in like the cache of the filesystem
+2024-05-28 20:49:35	~runxiyu	hax: ???
+2024-05-28 20:49:44	~runxiyu	why do filesystem caches have anything to do with this
+2024-05-28 20:49:44	&hax	essentially a special name sure
+2024-05-28 20:50:09	&hax	because kernel reads fs -> insert '.' and '..' dir into it with reference, carry on