Hacker News Reader

Comment by crvdgc | Hacker News Reader

> 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.

View on HN

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.

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?

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)

Wow that would be cool

That's maybe: https://github.com/p-e-w/maybe

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

I'm not affiliated with maybe, and it's also no longer maintained. I don't know if there's a newer, better tool out there.

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.

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

You can achieve the same thing in Linux with seccomp.

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.

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.

Yes, even a blacklist with obvious ones listed would be cool. Imagine just typing the characters rm and you're gone..

Good point. That's a big problem. I could conceivably have a perfectly harmless tool where a prefix of the name is something dangerous.

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 (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.)

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.

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

Reply on news.ycombinator.com