Hi.

With respect to /etc/crypttab:
1) Right now it's created by cryptsetup.preinst, but never cleaned up on purge.

2) I'd suggest to create it readable by root only.


Could provide a patch for both, if it helps you.


Cheers,
Chris.

Hi,

src:cryptsetup isn't the only consumer of /etc/crypttab, so this is a
wontfix.

Who else uses it that can work without cryptsetup? Systemd via
libcryptsetup? Then perhaps better to have a -common package that all
can depend upon, than leaving cruft behind after purge?


And still, one could tighten the permissions.

crypttab is part of our public API, and any (packaged or not) software
can hook into into without without explicitly depending on
cryptsetup-bin let alone cryptsetup.  Removing that API is a wontfix.

I don't think the cleanup is worth the extra metadata and package cruft
overhead…

I don't see why it makes more sense to og-rwx /etc/crypttab by default
compared to /etc/fstab or /etc/systemd/system.  If that makes sense in
YOUR environment, then YOU are free to do it manually; src:cryptsetup
control files shouldn't change existing permission/ownership (it'd be a
valid bug if they do).  Moreover tighter permissions have arguably
undesired side effects, such as broken bash completion for `sudo
cryptdisks_start <TAB>`.

Also FWIW /etc/crypttab is typically created by d-i, at least when a
using the “encrypted root FS” layout.  I don't have data at hand to back
that up, but I believe that preinst snippet is usually a noop.

Note however that if cryptsetup-initramfs is installed, and some disks
need to be unlocked at early boot, then a crypttab snippet is included
in the initramfs image.  That image is world-readable by default, so
extra steps need to be taken not to leak data.  Perhaps update-initramfs
should error out when it's about to generate a world-readable image
containing files/directories with restrictions, but it doesn't AFAIK.