Re-write of crypttab/cryptsetup handling - Request for peer review, wider testing.
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Re-write of crypttab/cryptsetup handling - Request for peer review, wider testing.
I don't know whether Pat will be interested in this or not (but if he is, he's welcome to it).
After the shellshock stuff occurred I started looking at the Slackware system scripts for bashisms with an eye to making them shell agnostic.
One of the first I noticed was the crypttab handling code in rc.S which uses arrays. What I expected to be a quick fix, ended up as an extensive rewrite, including adding support for the more useful subset of the options on the freedesktop.org/systemd crypttab page.
Anyway, the results of my labour are here, for any who feel adventurous and want to help me out with feedback and testing,(but don't apply it untested to any boxes you care about, just in case I got something wrong. ).
UPDATE 20/10: Updated the rc.cryptsetup to include the safety-check suggested by Eric. Now split into two separate patch files, one per package.
I like this, and you have my blessing :-) Pat will hopefully also be convinced and apply it.
The one thing that has always been missing in my LUKS implementation in rc.S, was a check right before encrypting a swap volume and enabling it. I have had one bug report in the past where someone added an extra harddisk to his computer, as a result the disk numbering changed and at boot, rc.S overwrote a data partition and turned it into swap.
Can you add a check for the existence of partitions with filesystems on the volume right before LUKS-ifying it as an encrypted swap?
The unconditionally nuke-it if its tagged 'swap' approach has always concerned me too. Might be able to do something with 'blkid' in order to preform a sanity check. Leave it with me.
I think adding a construct like this at the appropriate place will do the job:
Code:
blkid -p -n noswap $DEV && { echo "Not on your nelly!" ; continue ;}
A Normal filesystem will match the noswap filter and blkid will return 0.
A Swap partition or an empty partition will return 2.
The only thing that could be an issue is that as the partition may be left containing random data under some circumstances, though not in normal operation, its possible that blkid could be fooled into thinking that its a filesystem and trigger the fail-safe.
Need to do a bit more testing, but I think this is the best I'm going to come up with. If anyone has a better approach, I'm open to suggestions.
I have had one bug report in the past where someone added an extra harddisk to his computer, as a result the disk numbering changed and at boot, rc.S overwrote a data partition and turned it into swap.
The way I avoid that problem is by using /dev/disk/by-id/xxxx to identify the partition. That ID includes the drive serial number. Conversion to GPT can also eliminate the issue, since that gives each partition a UUID independent of the partition's content.
I think adding a construct like this at the appropriate place will do the job:
Code:
blkid -p -n noswap $DEV && { echo "Not on your nelly!" ; continue ;}
A Normal filesystem will match the noswap filter and blkid will return 0.
A Swap partition or an empty partition will return 2.
The only thing that could be an issue is that as the partition may be left containing random data under some circumstances, though not in normal operation, its possible that blkid could be fooled into thinking that its a filesystem and trigger the fail-safe.
Need to do a bit more testing, but I think this is the best I'm going to come up with. If anyone has a better approach, I'm open to suggestions.
I think adding this check is the fastest and best fix ATM. Using disk UUIDs would be a slightly better solution, but would be harder to implement.
Yep, I tend to treat LQ attachments as transitory and housekeep them after a few months to avoid leaving 'stale' stuff around. I really should sign up with github for these sorts of things.
I don't have the nicely formatted patch files anymore, but here's the raw rc.cryptsetup taken from my system.
P.S. I chose the quoting carefully as the different shell implementations can be inconsistent when escaping within double quotes. Here, see what happens when you use your "${a#\'}" in ash:
Yeah, I'm not surprised that syntax highlighters/checkers are having a hard time with it.
Though my original code works, that quoting is definitely ugly. Thinking about it, using a couple of intermediate variables should avoid the need for double-quoting and ought to work.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.