@drewdevault danger zone

@drewdevault I find interactive prompts kinda obnoxious to be honest. I will make that mistake maybe once then immediately escalate my shell.

How would this work with a privilege escalation tool that only requires you to enter your password in once? Would it just go? Would it make me enter my long-ass password again? At that point I'd just CTRL+C and use the escalation tool anyways.

@drewdevault this general category of function seems very scary to me. Consider the case where I had recently auth'd with sudo, so sudo doesn't prompt for a password. Now if I typo a cat command (and potentially either type ahead something that is interpreted as "yes", or get flustered and accidentally hit something for yes), I can suddenly end up doing something very destructive as root without the extra protection of being prompted for my password.

@drewdevault

disk destroyer (dd) is a correct old-school tool for this task, and I have found Balena Etcher to have good guardrails for routine use when burning SD cards with minimal risk of accidentally destroying a root volume.

@drewdevault Would be more useful if it could just open /dev/sda as root. I probably don't care to run whatever command as root, I just want to write to a restricted file.

@drewdevault good idea but I'm used to my hacky "cat disk.img | sudo tee /dev/sda > /dev/null" too much ...

@drewdevault Is there a way to move the authentication to a place not accessable by the current user/process but a person with hardware access?

@drewdevault I'd like this as either an option for the config or a flag that can be appended to the command. It's still convenient while requiring enough extra thought to prevent a disproportionate amount of people accidentally bricking their systems

@drewdevault I prefer the "command fails and i re-run" workflow.

@drewdevault
That makes me *cringe*. Not much else to discuss, to be frank.

Like others have said, I'd find it preferable if the command just fails with an explanatory message and leave it to the user to deal with the situation more appropriately (sudo or whatever).

@drewdevault A few ideas. I'd rather this be a choice first off (Disableable). Second, it's gotta ask me first before prompting for my password. Third, wouldn't it make more sense to give me temp access to the "disks" group instead of full root?

@drewdevault I use a udev rule that grants my user/group ownership of USB block devices. I prefer this approach because it doesn't require admin privileges to mess with a USB thumb drive and works for a guest users too.