Hacker News Reader

Comment by woodruffw | Hacker News Reader

I came across stderred a few months ago while looking to do the same thing on my terminals. I ultimately didn't go with it because people have reported destroying their systems while using it[1]. Wrapping libc (which is itself wrapping the actual syscall) is a tricky thing to do safely.

I looked into accomplishing the same thing with URxvt's pre- and post-text rendering hooks, but couldn't get it to work.

[1]: https://github.com/sickill/stderred/issues/63

View on HN

Not sure what update-initramfs does exactly, but if you ever close(2) your going to be in a world of hurt, because the next file you open is going to have a bunch of junk written to it.

At repl.it we don't put it in our .bashrc or anything like that, we call the wrapper program manually when we launch the user's binary.

Oof. We missed this issue -- good to know. So this is running in production right now for Repl.it beta users and seems to be working fine. But we only use it on the interpreter process and not globally.

Disappointed in the response over at Ubuntu: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+b...

IMO this should be treated as a bug in initramfs-tools.

This isn't an initramfs-tools bug–if you're LD_PRELOADing into a binary, presumably you know what you're doing. The "bug" here is setting LD_PRELOAD as root (if accidentally through sudo -s) and running a sensitive operation, knowing full well that stderred is a (admittedly very useful, since I use it!) hack at best.

I suggest that it actually is an initramfs-tools bug. As pointed out elsewhere in this very discussion, the program in question must be using file descriptor #2 as its output file descriptor for the files that get corrupted, because stderred only inserts its hardwired control sequences on writes to that file descriptor. That's a bad thing to be doing independent of stderred, because there is potentially other (library) code in the relevant program (whatever it is) that assumes that file descriptor #2 is usable for diagnostics. Even without stderred in the mix, it is a bug waiting to be triggered via another route.

Argh. This is a turn-off for sure but it seems like the issue can be easily remediated by stripping the color codes from the initrd image

Ideally, but it might not be reversible: if the same bytes that make up an ANSI escape + red color code just happen to already be in initrd, then the strip would remove those as well.

I think the best solution here is probably to avoid `sudo -E`, and for `stderred` to be patched to not perform any monkeypatching when `uid == 0`.

LD_PRELOAD is not respected for setuid binaries, right? So why do we need a special case here?

Because sudo is the setuid binary here (so it's not affected) but everything else isn't setuid, they're just running under sudo with LD_PRELOAD set...

sudo -E should not pass LD_PRELOAD through anyways; at least, the one I'm using on macOS 10.14.2 and the Ubuntu 14.04 box I just SSHed into doesn't do this. It looks like the issue is that sudo -s causes LD_PRELOAD to be set again as root because ~/.bashrc is sourced again.

Reply on news.ycombinator.com