11 ms·
This is awesome, but I am absolutely bloody terrified of using it on my systems. As is stated in the README, if you write 'rm' or anything like it... oopsie oo
by esotericn 8y ago
This is awesome, but I am absolutely bloody terrified of using it on my systems.
As is stated in the README, if you write 'rm' or anything like it... oopsie oops.
- nickspacek 8y agoHmm, is there a straightforward way to be a bit more careful without detracting from the usefulness? What about a default blacklist of commands with the ability to override it through a config file?
- rcthompson 8y agoI don't think a blacklist could possibly be comprehensive enough. I think you'd have to use some OS permission-limiting system to prevent it and any subprocesses it spawns from have any write access to the filesystem.
- esotericn 8y agoPretty much. Is rm blacklisted? OK. How about bash -c "rm"? cp? mv? vim? ...? :D
- y4mi 8y agoYah, a whitelist of commands which includes bash would probably be best. You'd be fine using it and can simply switch to chainsaw mode by adding bash to the command
- malkarouri 8y agoI think the tool would be much more useful with a whitelist. Do this only for grep, awk, sed and other similar tools. Of course, much more thought is needed to try something like this. Somebody could as well use awk with its system command to do whatever..
- deleted 8y ago[deleted]
- conquistadog 8y agoEven an incomplete blacklist might be helpful, just in the interest of keeping perfect from being the enemy of good.
- amelius 8y agoOr perhaps use filesystem snapshots as an undo option ... if your fs supports them, of course.
- akavel 8y agoAuthor here: I hope something like that (syscall/capabilities limits) could work. If it is possible, it would just mostly solve the problem, I believe. I'm kinda starting to realize, that probably any command modifying some external state is potentially somewhat risky already, by potentially spinning some exponential feedback loop. (One person on lobste.rs mentioned that foo.bak.bak.bak.bak files could easily get created.) Regardless, I'm generally considering adding a shortcut/option to pause/unpause, and only execute on Ctrl-Enter when paused.
- rcthompson 8y agoAnother possibly reasonable option would be to create a (configurable) whitelist of commands that are considered safe, and keep running the pipeline automatically as long as it only contains whitelisted commands. Any time a non-whitelisted command is introduced, stop auto-running and require Ctrl+Enter or something, until the command once again consists of only whitelisted commands. This would save you, for example, if you had a custom command called "gr" which was short for "get rid of current directory" (obviously chosen as a pathological example since it's a prefix of grep). As you type the word "grep", auto-running is paused because "g", "gr", and "gre" are not whitelisted, and then once "grep" is fully typed, it recognizes that "grep" is on the whitelist and resumes auto-running. And it never ran the dangerous "gr" command.
- michaelmior 8y agoI hate to jump straight to Docker, but that seems to be a quick way to restrict access to the local file system. This of course limits utility, but would be much safer. Plus I think the usefulness of a tool like up is primarily in munging the input text anyway.
- traverseda 8y agoDocker is an obviously bad solution to this. If you can run a docker file you defacto have root on that computer ^1. Firejail could do exactly the same thing, but without requiring the user running it download an entire second operating system, or requiring them to have root. Also, the sandboxing mechanisms that docker uses are just generally available and aren't hard to use, so if they went that way they may as well just use the actual syscalls that do what they want instead of importing and entire other operating system to run your commands. This is where my rant about docker, and the habits it encourages, would go. If I could figure out a way to phrase it politely. 1: https://github.com/moby/moby/issues/9976 https://github.com/moby/moby/issues/9976
- akavel 8y agoWow, firejail seems super interesting, thanks a lot for the idea and mention! I'm not sure if I'll manage to use it, but certainly a good direction for some further research! https://firejail.wordpress.com/ https://firejail.wordpress.com/
- fwip 8y agoDocker containers don't need to be (and often aren't) "entire operating systems." Good point about it requiring root, though.
- michaelmior 8y agoThe problem I was suggesting could be solved Docker wasn't with the privileges of up itself, but the problem of commands you write within up being potentially destructive. I didn't say I thought Docker was a good solution.
- Nullabillity 8y ago
- LyndsySimon 8y agoIf it could be activated only by hotkey, that would be helpful.
- mordechai9000 8y agoYes, maybe similar to the way tab completion works.
- jimbokun 8y agoThink a whitelist would be much more appropriate for avoiding potentially harmful commands.
- yipbub 8y agoMaybe a whitelist of commands it can run?
- _kst_ 8y agoA whitelist would make it far less useful. A blacklist would still make it possible to execute dangerous commands. The only solution that I would find acceptable would be not to execute incomplete commands as they're typed.
- setquk 8y agoYes this is an amazingly dangerous and stupid idea. Sure it looks cool but so does a Lamborghini until it catches fire or you crash it into a tree at 150mph. Giving a user an opportunity to correct mistakes before they kill themselves is a major feature of Unix. Sure when you’ve decided you know what you’re talking about but don’t it will quite obediently shoot your face off. We don’t want to make that bit easier though. Edit: please don’t take this as derision but more factual. It certainly looks cool and opens the idea for further discussion.
- LyndsySimon 8y agoDangerous, yes. Stupid, though? No. It’s a useful tool and a good idea that merely needs further refinement.
- jolmg 8y agoStupid is too harsh, and I don't want to discourage anyone from contributing to open source, but I'm not sure this is all that useful either (at least not to me). Is the utility in not having to press Enter because this'll do it for me between every character? I can only think that the reason people like it so much is because it looks cool or most people don't know how to use command line editing keybindings effectively and like that they won't have to hit up arrow and move slowly across the command to edit. The fact that it doesn't have readline support, timestamped history support, or output the output of the last command to stdout at the end already seem like feature losses when compared to using a shell normally.
- setr 8y agoAt least one neat benefit I can imagine is not flooding your history with 20 minor edits to a regex in a long pipeline, and not flooding your stdout with garbage from a bad regex Inversion of the output (viewing the top, instead of the bottom, without scrolling on longer outputs) is also of note Imagine if this were simply the shell, with all its normal editing facilities, but laid out in this fashion. It seems obvious to me theres a usefulness anytime you’re trying to create a longer pipeline.. and doing the same thing the shell normally, but leaving a mess behind Your list of issues are all resolvable (and probably trivially so), and thus not really relevant to the question of whether this thing is worth having in the first place (which requires more fundamental questioning). IE the issue with rm executing when you’re typing in ‘rmore’ is absolutely fatal in the current design and makes it unusable. That can’t be fixed without a bunch of hacks, or losing one of its main features (swapping to enter-to-run is more than fine imo). With such a fatal flaw, it could be fair to call it stupid and useless. But for lacking readline support on first public listing..?
- kozhevnikov 8y agoHow about not evaluating input until user hits a key, e.g. tab? Then any blame for rm lies squarely with the user.
- certifiedloud 8y agoThat's how bash works by default. This tool would be of no use if that's how it worked.
- kozhevnikov 8y agoBash does the autocompletion, but not evaluation and display of the output, does it not?
- setr 8y agoHe was referring to “hits a key” —> [enter]
- jolmg 8y agoRight, that's one problem. The author says: > But you'd be careful writing "rm" anywhere in Linux anyway, no? Also, why would you want to pipe something into "rm"? But the thing is that you don't need to intend to pipe to "rm". Maybe you were typing something else, like having a command "rmore" or something. This danger is also not strictly limited to `rm` and `dd`, and you have to be careful that no substrings from the start of the command you intend to write cannot be interpreted as something dangerous.
- clhodapp 8y agoIt seems like most of the scariness could go away if only you had to press a key combo each time you wanted to run the command / render the preview
- jolmg 8y agoYes. Like Enter? People might still like the fact that the cursor doesn't need to move from wherever it's editing the command to run it, and can still continue to edit there.
- akavel 8y agoThat's the main direction I currently seem to be coalescing on based on feedback I'm getting. That said, one person on lobste.rs suggested trying to play with Linux capabilities, to make the filesystem immutable... now that would be a seriously fancy trick if it works!
- rcthompson 8y agoConsider that the filesystem isn't necessarily the only thing you can mess up by accident. It's much more unlikely, but you could accidentally trigger a bunch of unwanted network requests (e.g. piping into `xargs curl` or something), among other possible things with external effects.
- 8y ago
- XorNot 8y agoIt does occur to me that if this did system-call redirection and banned the unlink (and maybe rename?) syscalls from working in it's executed commands, you could get a fair degree of safety.
- Bjartr 8y agoOne possible way to deal with some of those cases would be to intercept those commands and instead display something about what would happen e.g. `deletes 42 files`
- jknz 8y agoA solution is to have the tool run first in a container or sandbox where any changes can be rolled back ("test mode"). Once the command looks promising on the test container, run the command again in a fresh container to confirm, and maybe see a list of affected files. Finally run on the main filesystem outside of any test container. Edit: similar ideas with family snapshots already suggested elsewhere in the thread
- dan-robertson 8y agoI think most of the useful commands ought to be able to be run in a namespace where they can’t do much. Eg if they can’t see any files then they can’t delete them. Unfortunately they wouldn’t then be able to read config files. Eg I would expect grep looks for a config file to decide what colour to highlight matches and so on. Perhaps one could run them as a fresh user with few permissions, except it could still write to files if they are writable by “other”
- akavel 8y agoIs it possible to configure namespaces so that they allow read-only access?
- em-bee 8y agoi'd be ok with manually configuring up to tell it to copy certain config files to the sandbox so they are available for the commands to run there. there should not be to many commands that need configuring. greetings, eMBee.
- toxik 8y agoI feel like you could replace this tool with a hotkey that runs the current command without clearing the line, sort of ”what if I ran this as is”
- the8472 8y agoOne could sandbox the whole thing with an tmpfs+overlayfs to avoid such accidents.
- slewis 8y agoA potential solution is to create a user who has no or limited write access, and modify up so that it always switches to that user. I wonder if there’s a way to do this without requiring the creation of a new system user. Some way to revoke all write access for the current process.
- dharmab 8y agoCapabilities do this. It's the same mechanic used by containers to restrict their access. See man capabilities(7)
- drb91 8y agoSeems to be linux only at first blush.
- akavel 8y agoI'm ok with focusing on Linux as the prime target for up. Though I'm totally trying to think about cross-platform approaches too, obviously.
- codetrotter 8y agoFreeBSD has a capabilities system called “Capsicum”. https://www.freebsd.org/cgi/man.cgi?capsicum(4) https://www.freebsd.org/cgi/man.cgi?capsicum(4) https://wiki.freebsd.org/Capsicum https://wiki.freebsd.org/Capsicum https://www.cl.cam.ac.uk/research/security/capsicum/freebsd.html https://www.cl.cam.ac.uk/research/security/capsicum/freebsd.... Capsicum is convoluted though. OpenBSD has pledge and unveil, which from what I have seen are very elegant. https://man.openbsd.org/pledge.2 https://man.openbsd.org/pledge.2 https://man.openbsd.org/unveil https://man.openbsd.org/unveil
- deleted 8y ago[deleted]
- imhoguy 8y agoWouldn't it be possible to limit that by cgroups/namespaces? Possibly remounting everything as read-only.
- hawski 8y agoI was thinking about similar tool to this one and this was the biggest obstacle I could think of. Also write touch and create a file for each keystroke. To become something more than a hack you have a few choices: - a blacklist - will never be enough, still arguments may be problematic - a whitelist - will always be not enough, arguments may be problematic, but a bit less than with a blacklist - limiting permissions somehow - tricky The last and best option IMHO would be to wrap it in a sandbox, where all filesystem access is behind an overlay (i.e. mount namespaces and overlayfs). This way if you are satisfied you can apply changes (if there is anything to change). The overlay would be removed and created on each keypress. It may be also possible to wrap process access, so one could safely play with kill, but I'm not sure. Even network settings to some extent. But there is nothing you can do with curl -X POST or something similar.