1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
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
|
