The problem is that the permissions on /tmp are not set to 1777 as they should be. The after.local script is not called from systemd. I added a new systemd service to activate after.local and added the following lines to my after.local:
sleep 5
/bin/chmod 1777 /tmp
The sleep is necessary, unfortunately.
So there are two bugs here, ultimately:
Permissions aren’t set correctly for /tmp when an encrypted filesystem is in use
after.local is not called from systemd
This workaround works great for me, but ideally it would be great to have a proper fix.
>
> I’m using OpenSUSE 12.1 with systemd. I have encrypted tmp on a
> partition with the following crypttab line:
>
> cr_sda7 /dev/disk/by-id/ata-ST9500420AS_5VJEXZNT-part7
> /dev/urandom tmp
>
> The corresponding /etc/fstab line is as follows:
>
> /dev/mapper/cr_sda7 /tmp ext2 nofail,defaults
> 0 0
>
> The problem is that the permissions on /tmp are not set to 1777 as they
> should be. The after.local script is not called from systemd. I added
> a new systemd service to activate after.local and added the following
> lines to my after.local:
>
> sleep 5
> /bin/chmod 1777 /tmp
>
> The sleep is necessary, unfortunately.
>
> So there are two bugs here, ultimately:
>
> 1. Permissions aren’t set correctly for /tmp when an encrypted
> filesystem is in use
> 2. after.local is not called from systemd
>
> This workaround works great for me, but ideally it would be great to
> have a proper fix.
>
>
Tyr adding ‘mode=1777’ (without the quotes) to the options portion of the
/etc/fstab line. i.e.,
On 12/14/2011 10:06 AM, erikvcl wrote:
>
> I’m using OpenSUSE 12.1 with systemd. I have encrypted tmp on a
> partition with the following crypttab line:
>
> cr_sda7 /dev/disk/by-id/ata-ST9500420AS_5VJEXZNT-part7
> /dev/urandom tmp
>
> The corresponding /etc/fstab line is as follows:
>
> /dev/mapper/cr_sda7 /tmp ext2 nofail,defaults
> 0 0
>
> The problem is that the permissions on /tmp are not set to 1777 as they
> should be. The after.local script is not called from systemd. I added
> a new systemd service to activate after.local and added the following
> lines to my after.local:
>
> sleep 5
> /bin/chmod 1777 /tmp
>
> The sleep is necessary, unfortunately.
>
> So there are two bugs here, ultimately:
>
> 1. Permissions aren’t set correctly for /tmp when an encrypted
> filesystem is in use
> 2. after.local is not called from systemd
>
> This workaround works great for me, but ideally it would be great to
> have a proper fix.
Have you filed a bug report? That is the only way that the developers find out
about such problems.
This is not on you specific question, but is on the question of encrypted “/tmp”.
I considered using encrypted “/tmp”. But, instead, I chose to use encrypted swap, and then mount “/tmp” from swap (i.e. as tmpfs). My “fstab” line for that is:
On 2011-12-14 17:06, erikvcl wrote:
>
> I’m using OpenSUSE 12.1 with systemd. I have encrypted tmp on a
> partition with the following crypttab line:
>
> cr_sda7 /dev/disk/by-id/ata-ST9500420AS_5VJEXZNT-part7
> /dev/urandom tmp
>
> The corresponding /etc/fstab line is as follows:
>
> /dev/mapper/cr_sda7 /tmp ext2 nofail,defaults
> 0 0
>
> The problem is that the permissions on /tmp are not set to 1777 as they
> should be.
Once tmp is mounted, define the correct permissions for it, and they should
hold. However, I have the doubt if this is true seeing that you are using
urandom.
> The after.local script is not called from systemd. I added
> a new systemd service to activate after.local and added the following
> lines to my after.local:
You could instead edit “/etc/init.d/boot.crypto”, and add your hack.
> So there are two bugs here, ultimately:
>
> 1. Permissions aren’t set correctly for /tmp when an encrypted
> filesystem is in use
I think this is due to your use of random, this makes the system create a
new filesystem on boot.
> 2. after.local is not called from systemd
That one I guess will be closed as “invalid”, ie, it is intentional.
But of course, fill bugzillas on them, it is the best way. And tell us the
numbers, so that we can follow them.
–
Cheers / Saludos,
Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)
which worked fine. I consider it a bug when upgrade script breaks it. I don’t find documention that now mode= would be forbidden for ext4 or permanent filesystems. I don’t understand that apparently nobody is aware that this was configured by Yast’s partitioner when choosing encrypted partitions without password.
> Well I had in 11.4:
>
> /dev/mapper/cr_sda2 /tmp ext4
> mode=1777,acl,user_xattr,nofail 0 0
That’s bad syntax. Ext4 will not accept “mode=whatever”
> which worked fine.
I’m sure you got an error and ignored it. It might be in the logs.
> I consider it a bug when upgrade script breaks it. I
> don’t find documention that now mode= would be forbidden for ext4 or
man fstab, man mount. It has been documented for ages.
> permanent filesystems. I don’t understand that apparently nobody is
> aware that this was configured by Yast’s partitioner when choosing
> encrypted partitions without password.
If Yast wrote that line, report the bug. I doubt it did.
–
Cheers / Saludos,
Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)
On 2012-01-09 21:53, Carlos E. R. wrote:
> On 2012-01-09 20:06, erniecom wrote:
>> I don’t find documention that now mode= would be forbidden for ext4 or
>
> man fstab, man mount. It has been documented for ages.
I’ll clarify. See mount(8). Search for the section “FILESYSTEM INDEPENDENT
MOUNT OPTIONS”. Verify that “mode=” is not one of them. The next section is
“FILESYSTEM SPECIFIC MOUNT OPTIONS”. Then search for “mode=”. You will see
it in the sections for affs, devpts, iso9660", and tmpfs. Not for ext? types.
–
Cheers / Saludos,
Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)