From 8ab1b4e696ce1d09f39c2ee64c3fcb08150d539e Mon Sep 17 00:00:00 2001 From: Runxi Yu Date: Sun, 9 Jun 2024 09:43:08 +0800 Subject: expand tabs in llpath.txt --- llpath.txt | 184 ++++++++++++++++++++++++++++++------------------------------- 1 file 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 -- cgit 1.4.1-2-gfad0 href='#n364'>364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753