On Sat, 2021-09-11 at 20:06 +0200, Guilhem Moulin wrote: > I was about to reply “like fsttab(5)” but it seems fstab-decode(8) > doesn't mangle ‘\xHH’, ‘\t’ or ‘\n’. AFAICS, at least \xHH is not specified for that in at least POSIX: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/echo.html
dash, doesn't seem to do it either, but bash does. > So either I misremembered testing > this at the time, or something changed meanwhile :-) I'd argue that > ‘\’ > is a special character which per documentation “needs to be escaped > using octal sequences”, so both ‘\n’ and ‘\xHH’ yield unspecified > behavior, but I guess that can be made explicit. Maybe the easiest is simply to write e.g.: Every field of crypttab is unescaped using printf(1)’s “%b” conversion specification, which unescapes the \-escapes (\n, \t, \0num, etc.) as provided by the echo utility. Than we're always automatically on the safe side. > We assume that unprivileged users do not have write access to > /etc/crypttab (actually, $TABFILE), keyscripts, or initramfs hook/ > scripts. Otherwise one can replace askpass with `mail > m...@example.net`, > append ‘keyscript=gimme_your_password’ to crypttab entries, or simply > ship compromised executables in the initramfs image. I'd still suggest to document that (and not just assume it silently)... otherwise some smartypants admins might thinkt it's ok to allow users to just append entries to crypttab in some way they think it would be secure. Cheers, Chris.
