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