Bug 663995

restorecon /var/log/pm-suspend.log 

For some reason this file got created with the wrong label.

Did you run pm-suspend manually?

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

(In reply to comment #1)
> restorecon /var/log/pm-suspend.log 
> 
> For some reason this file got created with the wrong label.
> 
> Did you run pm-suspend manually?

Yes, I did (with constantly crashing gnome-power-manager, it was the only way how to suspend). Why just plain

sudo pm-suspend

is not allowed?

I think I already have a bug report to switch pm-utils to append output to its log files rather then write to them.

Bug 660329 description was already committed and present in pm-utils-1.4.1-3.fc15, probably it doesn't resolve this problem.

I believe that will fix this bug.

*** This bug has been marked as a duplicate of bug 660329 ***

Sorry, it still does not work. The boot sequence seems clean, but the pm-suspend still emits AVC, thus reopening this one.

The problem: the init_logfile is called before every suspend, thus the /var/log/pm-suspend.log is recreated with wrong label, the code:

rm -f "$1"
exec >> "$1" 2>&1

This is the feature of pm-utils to store only the last suspend log.

What AVC?

From comment 0 (description) of this bug.

Fixed in selinux-policy-3.9.12-2.fc15

This exact bug just happened to me after running pm-hibernate, with:

selinux-policy-3.9.14-2.fc15.noarch
pm-utils-1.4.1-5.fc15.x86_64

ls -lZ /var/log/pm-utils.log
restorecon /var/log/pm-utils.log

The question is how did it get mislabelled.

What is the exact AVC that you got?

Created attachment 484216 [details]
SETroubleshoot log after resume

Still problem on F15.

Currently the pm-utils rm the /var/log/pm-suspend.log file before suspend and the newly created log file is labelled var_log_t. It can be relabelled to devicekit_var_log_t by:

# /sbin/restorecon -v /var/log/pm-suspend.log
/sbin/restorecon reset /var/log/pm-suspend.log context unconfined_u:object_r:var_log_t:s0->system_u:object_r:devicekit_var_log_t:s0

# ls -Z /var/log/pm-suspend.log
-rw-r--r--. root root system_u:object_r:devicekit_var_log_t:s0 /var/log/pm-suspend.log

but after the next suspend:
# pm-suspend
...
[resume]
# ls -Z /var/log/pm-suspend.log
-rw-r--r--. root root unconfined_u:object_r:var_log_t:s0 /var/log/pm-suspend.log

Current code in /usr/lib[64]/pm-utils/pm-functions:

# Try to reinitalize the logfile. Fail unless certian criteria are met.
init_logfile()
{
...
        rm -f "$1"
        exec >> "$1" 2>&1
}

        rm -f "$1"
        touch "$1"
        restorecon "$1"
        exec >> "$1" 2>&1

Will make SELinux stop complaining.

Or 
        > "$1"
        restorecon "$1"
        exec >> "$1" 2>&1

Dan, thanks, but I am now getting another AVC before each suspend:

type=AVC msg=audit(1300360173.707:606): avc:  denied  { read } for  pid=6185 comm="restorecon" path="/var/run/pm-utils/locks/pm-powersave.lock" dev=tmpfs ino=174719 scontext=unconfined_u:unconfined_r:setfiles_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:devicekit_var_run_t:s0 tclass=file

the code in ./pm-utils/functions:
try_lock()
{
	# $1 = file to use as lockfile
	local lock="${LOCKDIR}/${1##*/}"

	# make sure the directory where the lockfile should be exists
	mkdir -p "${LOCKDIR}"
	touch "${lock}"
	exec 3<"${lock}"
	flock -x -n 3 || return 1
	return 0
}

Ok that one we will need to fix.

Fixed in selinux-policy-3.9.16-5.fc15

Thanks, now it is OK.

pm-utils-1.4.1-6.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/pm-utils-1.4.1-6.fc15

pm-utils-1.4.1-6.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.