OpenSUSE 12.1 encrypted tmp workaround

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.

Need to report this on Bugzilla no developers here

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.
>
>

Tyr adding ‘mode=1777’ (without the quotes) to the options portion of the
/etc/fstab line. i.e.,

/dev/mapper/cr_sda7 /tmp ext2 nofail,defaults,mode=1777 0 0

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.

Tried that, doesn’t work

Will do, thanks. Until it’s actually fixed, others can see there’s a workaround.

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:



/dev/mapper/cr_sda8    swap                 swap       defaults              0 0
## above is for defining swap
...
none            /tmp    tmpfs   size=100m       0 0
### above defines "/tmp"

I did define a larger swap partition than I would otherwise have used. I am not having any problems with “/tmp” permissions when done that way.

That’s a great idea, thanks. I didn’t know how tmpfs worked – or that it was so easy. I already use encrypted swap (as well as encrypted tmp).

Instead of the “size=100m”, you can use “defaults” if you don’t want to limit “/tmp”. The default is to size it to half the available swap+memory.

On 2011-12-14 17:12, George Baltz wrote:
> Tyr adding ‘mode=1777’ (without the quotes) to the options portion of the
> /etc/fstab line. i.e.,

That only works for FAT partitions.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

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)

No, it works fine with /tmp, at least on 11.4. From my desktop:

gwb@cloyd:~> ls -ld /tmp
drwxrwxrwt 15 root root 360 Dec 16 11:45 /tmp
gwb@cloyd:~> grep /tmp /etc/fstab
tmpfs                /tmp                 tmpfs      size=64M,mode=1777    0 0

Without the mode=1777, I get no sticky-bit on /tmp (0777).

That’s why I was surprised when the OP said it didn’t work. Hope that’s not another systemv/systemd gotcha.

On 2011-12-16 18:06, GeoBaltz wrote:

>> That only works for FAT partitions.
>>
>>
>
> No, it works fine with /tmp, at least on 11.4. From my desktop:

Ah, but you are using tmpfs. That’s different.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

Well I had in 11.4:

/dev/mapper/cr_sda2 /tmp ext4 mode=1777,acl,user_xattr,nofail 0 0

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.

On 2012-01-09 20:06, erniecom wrote:

> 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)