Description of problem: The crypttab(5) manpage describes a "read-only" option that allows setup of a read-only encrypted block device. When this option is added to /etc/crypttab, it has no effect. The device is still read/write: [root@totoro ~]# grep d0 /etc/crypttab d0 UUID=de7505bf-9f28-4295-ae7a-b3e8bd456c8e none read-only [root@totoro ~]# cryptsetup status d0 /dev/mapper/d0 is active and is in use. type: LUKS1 cipher: aes-cbc-essiv:sha256 keysize: 256 bits device: /dev/sdb1 offset: 4096 sectors size: 5860525072 sectors mode: read/write [root@totoro ~]# Version-Release number of selected component (if applicable): systemd-197-1.fc18.1.x86_64 cryptsetup-1.5.1-1.fc18.x86_64 How reproducible: Always Steps to Reproduce: (See the description.)
Looking at the systemd tree: * src/cryptsetup/cryptsetup-generator.c passes the options as-is from /etc/crypttab via unit files to src/cryptsetup/cryptsetup.c * In src/cryptsetup/cryptsetup.c, parse_one_option() seems to parse the "readonly" option. But the option in /etc/crypttab as documented in the crypttab(5) manpage is "read-only" (with the hyphen). So one or the other has to be changed to be consistent, or parse_one_option() has to be updated to accept both "readonly" and "read-only". I hope this helps to resolve this bug, and an update is released soon for it.
Thanks for finding this. systemd's crypttab(5) manpage is wrong. The code accepts "readonly". The crypttab(5) manpage in Debian also says "readonly". We could just fix the manpage, but for consistency in naming of multi-word options it would be prettier to have "read-only". So let's accept both spellings.
Created attachment 690817 [details] cryptsetup: accept both "read-only" and "readonly" spellings I can't push this upstream right now, but will do it later today.
fixed upstream: http://cgit.freedesktop.org/systemd/systemd/commit/?id=18cf1a1be5ae6985f211ec6f02504506da36b223
systemd-201-2.fc18.1 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/systemd-201-2.fc18.1
Package systemd-201-2.fc18.2: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-201-2.fc18.2' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.2 then log in and leave karma (feedback).
Package systemd-201-2.fc18.4: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-201-2.fc18.4' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.3 then log in and leave karma (feedback).
Package systemd-201-2.fc18.5: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-201-2.fc18.5' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.5 then log in and leave karma (feedback).
systemd-201-2.fc18.6 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.6
Package systemd-201-2.fc18.6: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-201-2.fc18.6' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.6 then log in and leave karma (feedback).
systemd-201-2.fc18.6 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.