Bug 250881

Created attachment 160685 [details]
/etc/crypttab showing /tmp filesystem entry

Created attachment 160686 [details]
Matching /etc/fstab

This is a bug in the initscripts, it should run restorecon or whatever the
correct selinux commandline is to create the context for newly created filesystems.

Btw. you may want to use tmpfs for /tmp instead, when you have encrypted swap.
It will first use the ram to store the contents of the fs and when there is not
enough place it uses swap. Also you should not forget /var/tmp.

Is this also a bug that won't be fixed until a new initsystem is found for Fedora?

I don't see why this has to do with initscripts at all. The correct type should
be properly inhereited - we don't do restorecon on /sys or /proc....

The proper contexts are:

  \    system_u:object_r:root_t
  \tmp system_u:object_r:tmp_t

So isn't the wrong type inherited upon creation and needs to be changed to match
the policy?

(In reply to comment #6)
> The proper contexts are:
> 
>   \    system_u:object_r:root_t
>   \tmp system_u:object_r:tmp_t
> 
> So isn't the wrong type inherited upon creation and needs to be changed to match
> the policy?

From manpage reading I assume that after the mke2fs the filesystem should be
mounted to e.g.
/var/tmp/temp-root-XXXXX/tmp
and then run
setfiles -r /var/tmp/temp-root.XXXXX/ /path/to/correct/selinux-context-specfile
/var/tmp/temp-root.XXXXX/tmp /var/tmp/temp-root.XXXXX/tmp/lost+found

But I do not know how to find out which selinux-context-specfile would be right.
Imho this is more or less the same as the chmod 1777 call in rc.sysinit, so it
would not be wrong to do this in rc.sysinit. Otherwise it would be nice to have
an option to mount that makes sure that the filesystem is restoreconed before it
is completely available for the system. I guess I will file an RFE for this.

file_t means that a file exists on the file system without a label.  restorecon
looks at the systems defaults based on file paths and labels appropriately. 

Does the crypttab cause the file system to get created on every boot?  

If not, then labeling it once is all that is needed.  You could also use the
mount -o context=system_u:object_r:tmp_t:s0 

command line option to force the file system to be labeled tmp_t.

(In reply to comment #8)

> Does the crypttab cause the file system to get created on every boot?  

Yes, this is the case.
 
> If not, then labeling it once is all that is needed.  You could also use the
> mount -o context=system_u:object_r:tmp_t:s0 

Hm, this is a useful workaround.

(In reply to comment #5)
> I don't see why this has to do with initscripts at all. The correct type should
> be properly inhereited - we don't do restorecon on /sys or /proc....

Btw. in rc.sysinit in Fedora 7, there you already do restorecon for one dir in
/tmp, so why is it a problem to do it for the whole filesystem?

889 [ -n "$SELINUX_STATE" ] && restorecon /tmp/.ICE-unix >/dev/null 2>&1

Hm, and I also noticed that some file before this:
878 # Clean up various /tmp bits
879 [ -n "$SELINUX_STATE" ] && restorecon /tmp

So actually the code to fix this bug is already there, which leaves it unclear
whether this was wrongly reported or silently fixed.

Question to the reporter:
Do you still see this bug? Which version of initscripts do you use and how do
you run selinux, i.e. which policy and which mode (permissive or enforcing afaik)?

I still see this bug, but am now running Fedora 8. I don't have access to a FC7
machine.

I guess you did not see this question:
How do you run selinux, i.e. which policy and which mode (permissive or enforcing)?

I am running the targeted policy in enforcing mode.

initscripts-8.60-1

This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Out of curiousity, what happens if you apply the change in:

http://git.fedorahosted.org/git/initscripts.git?p=initscripts.git;a=commit;h=60ae2cf1f6494b3036f1126f88f71f0ab77e5e74

That didn't help, but I notice another clue. During the init process, there are
errors just after the message:

  Remounting root filesystem in read-write mode: " mount -n -o remount,rw

that say that /dev/mapper/tmp and /dev/mapper/var-tmp do not exist. They do
eventually mount, however, since they appear as mounted after the system is
fully started. Is it possible they are not mounted at the time restorecon is
run, perhaps because disk encryption is not started early enough during init?

Changing version to F9.

The problem is due to to problems in rc.sysinit

1. The RNG is started after local file systems are mounted. If, as in my case,
/tmp and /var/tmp are encrypted with random keys, these aprtitions can't be
mounted at the correct time. Moving the RNG initialization to just before
mounting local file systems fixes this problem. However, logic to mount /var
first, it it is not part of the root partition is also needed so the RNG can
have /var/lib/random-seed is also needed to cover all cases. I haven't done this.

2. /var/tmp needs to be added to the restorecon command that operates on /tmp as
part of the "Clean up various /tmp bits" section. This sets the proper context
for /var/tmp as well as /tmp.

I'll attach a diff against rc.sysinit.

Created attachment 310746 [details]
diff -u between original and modified /etc/rc.d/rc.sysconfig

Updating summary to better match problem.

Problem still exists in initscripts-8.76.3-1.i386

This bug has been triaged

diff -u between original and modified /etc/rc.d/rc.sysconfig for 
initscripts-8.76.4-1.i386

Created attachment 321925 [details]
diff for patched rc.sysinit for initscripts-8.76.4-1.i386

This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

The comment #24 doesn't cleanly apply, but I tried hacking rc.sysinit such that "Initialize pseudo-random number generator" and "if [ -f /etc/crypttab ]" were before "Mount all other filesystems", 

I guess there have been other changes in rc.sysinit

F11 initscripts-8.95-1.i586

This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Still seems to be an issue on F13 -- at least, enabling a tmp option in /etc/crypttab doesn't result in that device being available and active in /dev/mapper.

*** Bug 665876 has been marked as a duplicate of this bug. ***

This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.