3 ms·

Only if random-app is well-behaved (and if you knew it was you could just use `random-app ./myfile.txt`). $ echo foo > a.txt $ <a.txt ( echo bar >/proc/sel

by a1369209993 4y ago

Only if random-app is well-behaved (and if you knew it was you could just use `random-app ./myfile.txt`). $ echo foo > a.txt $ <a.txt ( echo bar >/proc/self/fd/0 ) $ cat a.txt bar

NoZebra120vClip 4y ago
That's bizarre and perverse! Surely someone has brought it up as a bug before that stdin is read-write! Is there some Posix standard preventing the standard shells from opening stdin as read-only???
- a1369209993 4y ago
  stdin is readonly. `<a.txt ls /proc/self/fd/0` generally gives 'lr-x------' for the permissions. The problem is that having a open file descriptor to a file lets a program get and/or act-as-if-it-had a path to the file; /proc/self/fd/ is just the easiest way to do that.
  - NoZebra120vClip 4y ago
    So the thing is that this is a nothingburger. Just because you gave a pathname to an untrusted app means nothing. You've already trusted the app with your user account. It could already overwrite or vandalize that file no matter how you invoked it. Just because you indicate that file is special to you doesn't change anything in the threat model here. For all you know, the app could just traverse the entire directory tree and trash every file it could possibly write to, or just confine the damage to your $HOME. There's no reason IMHO to avoid using a file as an argument, or directly as stdin. If you don't trust an app, don't run it in your user account; you run it in a sandbox, right? This is 2023. Now a case could be made for defending against misbehavior by an app that might write to an fd by mistake, but as a1369209993 demonstrates, writing to stdin is a very deliberate choice, as you'll need to look up a pathname and deliberately open that file as writable. That's not misbehavior, that's malice, and that doesn't belong anywhere near your user account in the first place.
  - NoZebra120vClip 4y ago
    Ah, I believe I see what's happening there. So, hiding the pathname from an untrusted tool via an unnamed pipe is a Posix security measure. Still bizarre! Who was the guy who awarded UUOC prizes? Wasn't he a real dyed-in-the-wool security wonk?

Only if random-app is well-behaved (and if you knew it was you could just use `random-app ./myfile.txt`). $ echo foo > a.txt $ <a.txt ( echo bar >/proc/self/fd/0 ) $ cat a.txt bar

NoZebra120vClip 4y ago

That's bizarre and perverse! Surely someone has brought it up as a bug before that stdin is read-write! Is there some Posix standard preventing the standard shells from opening stdin as read-only???

a1369209993 4y ago
stdin is readonly. `<a.txt ls /proc/self/fd/0` generally gives 'lr-x------' for the permissions. The problem is that having a open file descriptor to a file lets a program get and/or act-as-if-it-had a path to the file; /proc/self/fd/ is just the easiest way to do that.
- NoZebra120vClip 4y ago
  So the thing is that this is a nothingburger. Just because you gave a pathname to an untrusted app means nothing. You've already trusted the app with your user account. It could already overwrite or vandalize that file no matter how you invoked it. Just because you indicate that file is special to you doesn't change anything in the threat model here. For all you know, the app could just traverse the entire directory tree and trash every file it could possibly write to, or just confine the damage to your $HOME. There's no reason IMHO to avoid using a file as an argument, or directly as stdin. If you don't trust an app, don't run it in your user account; you run it in a sandbox, right? This is 2023. Now a case could be made for defending against misbehavior by an app that might write to an fd by mistake, but as a1369209993 demonstrates, writing to stdin is a very deliberate choice, as you'll need to look up a pathname and deliberately open that file as writable. That's not misbehavior, that's malice, and that doesn't belong anywhere near your user account in the first place.
- NoZebra120vClip 4y ago
  Ah, I believe I see what's happening there. So, hiding the pathname from an untrusted tool via an unnamed pipe is a Posix security measure. Still bizarre! Who was the guy who awarded UUOC prizes? Wasn't he a real dyed-in-the-wool security wonk?