diff options
Diffstat (limited to 'llpath.txt')
| -rw-r--r-- | llpath.txt | 184 |
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 |