expand tabs in llpath.txt

1 files changed, 92 insertions, 92 deletions

diff --git a/llpath.txt b/llpath.txt
index e276735..b179b35 100644
--- a/llpath.txt
+++ b/llpath.txt
@@ -1,92 +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
+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