On Sat, 11 Sep 2021 at 18:31:33 +0200, Christoph Anton Mitterer wrote: > On Sat, 2021-09-11 at 18:06 +0200, Guilhem Moulin wrote: >> Not wrong in my view, but incomplete and using undocumented escape >> sequences yields unspecified behavior. > > Well the problem is simply that anyone who uses in any of the fields > e.g. \n will end up getting a true newline and not the literal \n, as > one would assume from the documentation, which just mentions the octal > escapes.
I was about to reply “like fsttab(5)” but it seems fstab-decode(8)
doesn't mangle ‘\xHH’, ‘\t’ or ‘\n’. 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.
> Btw, there might also be a subtle security issue:
>
> If, for some reason, normal users are allowed to directly or indirectly
> control the contents of crypttab, they could probably inject shell code
> here:
> eval "CRYPTTAB_OPTION_$OPTION"='${VALUE-yes}'
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.
--
Guilhem.
signature.asc
Description: PGP signature
