4 ms·

> WARNING: Please be careful when using it! It could be dangerous. In particular, writing "rm" or "dd" into it could be like running around with a chainsaw. But

by crvdgc 6y ago

> WARNING: Please be careful when using it! It could be dangerous. In particular, writing "rm" or "dd" into it could be like running around with a chainsaw. But you'd be careful writing "rm" anywhere in Linux anyway, no? Side effects always seems like potential disasters for me.

jackhalford 6y ago
if linux had openbsd's pledge(2) then you could disable filesystem writes, which you don't need for grepping. I know linux probably has orher mechanisms to achieve the same result but in this situation pledge seems natural.
- dan-robertson 6y ago
  Probably that’s right. But note that sort, for example, may need to write to (temporary) files. So disabling writes entirely is probably not a sufficient solution
- 10000truths 6y ago
  You can achieve the same thing in Linux with seccomp.
onli 6y ago
Why side effects? It's about the main effect of tools like rm or dd. Some things just don't fit to live previews like provided by UP.
- nabakin 6y ago
  You don't want to accidentally delete or write to things and this command seems like an accident waiting to happen. A command whitelist would be very helpful but it doesn't look like UP has one.
  - dmingod666 6y ago
    Yes, even a blacklist with obvious ones listed would be cool. Imagine just typing the characters rm and you're gone..
    - michaelmior 6y ago
      Good point. That's a big problem. I could conceivably have a perfectly harmless tool where a prefix of the name is something dangerous.
    - akavel 6y ago
      One of the reasons for not doing this is that I decided I don't want to lure the users into a false sense of security. A comment by hnlmorg basically sums this up better than I could: https://news.ycombinator.com/item?id=26645875 https://news.ycombinator.com/item?id=26645875 (The other being, that I was cutting corners on my initial ideas brutally trying to push the tool out of the door, and it's still kind of a miracle I eventually managed to do that.)
mimimi31 6y ago
I remember reading about a project that let you "preview" the effects (e.g. file changes) of terminal commands by using ptrace to intercept the syscalls and just logging them instead. Maybe you could do something similar here to prevent accidental file deletions.
- nabakin 6y ago
  My first thought was to sandbox the executable but this sounds even better. Is it hard to implement the interception of all syscalls? And can file reads be distinguished from file writes?
  - simcop2387 6y ago
    Not terribly hard to do, and yes you can distinguish reads, writes, etc. A tool to log syscalls to see what might be possible is strace, it's incredibly useful for debugging a misbehaving application that either you don't have all the source for or it's gigantic codebase that you don't understand. Seeing which files a program is looking for is often all you need to figure out why it's behaving the way it is (i.e. locating an undocumented/badly documented/incorrectly documented config file)
- alvarlagerlof 6y ago
  Wow that would be cool
- minxomat 6y ago
  That's maybe: https://github.com/p-e-w/maybe https://github.com/p-e-w/maybe
  - adictator 6y ago
    Wow. That sounds like a really handy tool. Can it be used to debug programs, maybe?
  - akavel 6y ago
    Please note that up respects $SHELL, so if you find a way to set $SHELL to point to maybe (possibly wrapped in some helper script) in a useful manner, it might actually work! I'd highly appreciate an issue with a report/guide for that then on up, others might find that helpful! For details, see: https://github.com/akavel/up/releases/tag/v0.3 https://github.com/akavel/up/releases/tag/v0.3
nonbirithm 6y ago
Chrome's developer tools have live preview, and they apparently accomplish this at the VM level by blacklisting a set of impure bytecodes when running the code in a separate evaluation context. If one of the bytecodes is found then it throws an exception. I kind of wish LuaJIT had something like that.
haolez 6y ago
Is there a way to start a new instance of bash with read-only permissions only? This could easily fix the side-effects issue.

by crvdgc 6y ago

jackhalford 6y ago

if linux had openbsd's pledge(2) then you could disable filesystem writes, which you don't need for grepping. I know linux probably has orher mechanisms to achieve the same result but in this situation pledge seems natural.

dan-robertson 6y ago
Probably that’s right. But note that sort, for example, may need to write to (temporary) files. So disabling writes entirely is probably not a sufficient solution
10000truths 6y ago
You can achieve the same thing in Linux with seccomp.

onli 6y ago

Why side effects? It's about the main effect of tools like rm or dd. Some things just don't fit to live previews like provided by UP.

nabakin 6y ago
You don't want to accidentally delete or write to things and this command seems like an accident waiting to happen. A command whitelist would be very helpful but it doesn't look like UP has one.
- dmingod666 6y ago
  Yes, even a blacklist with obvious ones listed would be cool. Imagine just typing the characters rm and you're gone..
  - michaelmior 6y ago
    Good point. That's a big problem. I could conceivably have a perfectly harmless tool where a prefix of the name is something dangerous.
  - akavel 6y ago
    One of the reasons for not doing this is that I decided I don't want to lure the users into a false sense of security. A comment by hnlmorg basically sums this up better than I could: https://news.ycombinator.com/item?id=26645875 https://news.ycombinator.com/item?id=26645875 (The other being, that I was cutting corners on my initial ideas brutally trying to push the tool out of the door, and it's still kind of a miracle I eventually managed to do that.)

mimimi31 6y ago

I remember reading about a project that let you "preview" the effects (e.g. file changes) of terminal commands by using ptrace to intercept the syscalls and just logging them instead. Maybe you could do something similar here to prevent accidental file deletions.

nabakin 6y ago
My first thought was to sandbox the executable but this sounds even better. Is it hard to implement the interception of all syscalls? And can file reads be distinguished from file writes?
- simcop2387 6y ago
  Not terribly hard to do, and yes you can distinguish reads, writes, etc. A tool to log syscalls to see what might be possible is strace, it's incredibly useful for debugging a misbehaving application that either you don't have all the source for or it's gigantic codebase that you don't understand. Seeing which files a program is looking for is often all you need to figure out why it's behaving the way it is (i.e. locating an undocumented/badly documented/incorrectly documented config file)
alvarlagerlof 6y ago
Wow that would be cool
minxomat 6y ago
That's maybe: https://github.com/p-e-w/maybe https://github.com/p-e-w/maybe
- adictator 6y ago
  Wow. That sounds like a really handy tool. Can it be used to debug programs, maybe?
- akavel 6y ago
  Please note that up respects $SHELL, so if you find a way to set $SHELL to point to maybe (possibly wrapped in some helper script) in a useful manner, it might actually work! I'd highly appreciate an issue with a report/guide for that then on up, others might find that helpful! For details, see: https://github.com/akavel/up/releases/tag/v0.3 https://github.com/akavel/up/releases/tag/v0.3

nonbirithm 6y ago

Chrome's developer tools have live preview, and they apparently accomplish this at the VM level by blacklisting a set of impure bytecodes when running the code in a separate evaluation context. If one of the bytecodes is found then it throws an exception. I kind of wish LuaJIT had something like that.

haolez 6y ago

Is there a way to start a new instance of bash with read-only permissions only? This could easily fix the side-effects issue.