Bug 736847

Summary:	Permissions on /tmp not set when using encrypted tmp
Product:	[openSUSE] openSUSE 12.1	Reporter:	Erik Lotspeich <erik>
Component:	Basesystem	Assignee:	Frederic Crozat <fcrozat>
Status:	RESOLVED FIXED	QA Contact:	E-mail List <qa-bugs>
Severity:	Normal
Priority:	P5 - None	CC:	lnussel, r
Version:	Final
Target Milestone:	---
Hardware:	x86-64
OS:	Other
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Erik Lotspeich 2011-12-14 16:31:33 UTC

User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20100101 Firefox/8.0

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.

Reproducible: Always

Steps to Reproduce:
Use /etc/crypttab & /etc/fstab lines as shown in bug description.
Actual Results:  
The tmp filesystem is mounted correctly but the /tmp directory does not have the correct permissions.

Expected Results:  
/tmp directory permissions set to 1777

Comment 1 René Nieuwburg 2012-01-09 18:49:18 UTC

Related to this, when you upgrade from previous version with this in fstab:

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

Then after the upgrade the mode=1777 is removed. When you try to manually repair it you get the error: Unrecognized mount option "mode=1777" or missing value

Comment 2 Kun Kun Zhang 2012-03-09 03:11:46 UTC

Long time no response.So closed.Feel free to reopen it.Thanks.

Comment 3 Erik Lotspeich 2012-03-09 03:23:07 UTC

I do not understand why this bug would be closed due to lack of response.  I am not sure what type of response you expect from me, the original reporter.  The workaround I use today is that I carve /tmp out of encrypted swap using tmpfs (e.g. none            /tmp    tmpfs   size=100m       0 0), but this certainly isn't a fix.  This is still a valid bug and I don't believe it should be closed unless it is fixed.

Comment 4 Ludwig Nussel 2012-04-02 07:23:06 UTC

systemd bug

Comment 5 Frederic Crozat 2012-04-10 12:19:45 UTC

could you try to remove nofail in the options ?

Comment 6 Erik Lotspeich 2012-04-10 13:53:12 UTC

(In reply to comment #5)
> could you try to remove nofail in the options ?

This does not work either -- I added nofail to try to get it to work based in a suggestion in a forum.  I forget the exact behavior, but I believe the system doesn't finish booting without the nofail.

Comment 7 Frederic Crozat 2012-04-10 15:05:14 UTC

for the record, mode=xxx won't work on a ext* or btrfs filesystem (it is accepted on tmpfs), so it is normal to be ignored by mount.

Comment 8 Frederic Crozat 2012-04-10 16:09:04 UTC

I've just tested on a 12.1, with all updated install and with /tmp crypted with /dev/urandom and it is correctly mounted with 1777 for /tmp

Which version of systemd package are you using ?

Please make sure you have all maintenance update applied.

Comment 9 Erik Lotspeich 2012-04-10 16:12:56 UTC

(In reply to comment #8)
> I've just tested on a 12.1, with all updated install and with /tmp crypted with
> /dev/urandom and it is correctly mounted with 1777 for /tmp
> 
> Which version of systemd package are you using ?
> 
> Please make sure you have all maintenance update applied.

I reported this bug some time ago right after the 12.1 release.  I haven't tried since then though I know there have been at least 2 systemd updates.  I will try again.  Thanks.

Comment 10 Stefan Behlert 2012-06-19 11:57:42 UTC

comment 8 sounds like this is fixed. If you have different information after updating, please reopen.