Bug 922958

Ok, I am able to reproduce it

type=AVC msg=audit(1363551167.500:327): avc:  denied  { create } for  pid=737 comm="lightdm" name=".dmrc.QLEXTW" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:user_home_t:s0 tclass=file
type=AVC msg=audit(1363551167.500:327): avc:  denied  { write } for  pid=737 comm="lightdm" path="/home/mgrepl/.dmrc.QLEXTW" dev="dm-8" ino=666940 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:user_home_t:s0 tclass=file
type=SYSCALL msg=audit(1363551167.500:327): arch=c000003e syscall=2 success=yes exit=12 a0=215cb70 a1=c2 a2=1b6 a3=0 items=0 ppid=1 pid=737 auid=4294967295 uid=1000 gid=1000 euid=1000 suid=0 fsuid=1000 egid=1000 sgid=0 fsgid=1000 ses=4294967295 tty=(none) comm="lightdm" exe="/usr/sbin/lightdm" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1363551167.514:328): avc:  denied  { rename } for  pid=737 comm="lightdm" name=".dmrc.QLEXTW" dev="dm-8" ino=666940 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:user_home_t:s0 tclass=file

Does .dmrc.QLEXTW need to be random?

Yes, it appears to be random.

We can make it not be random, if that helps.

Or could it be placed in a subdir or ~/.cache?  Say 
~/.cache/lightdm/dmrc

Or just 

~/.cache/dmrc

Sure, we can adjust things to use something under ~/.cache as a temp filename instead (before it gets renamed back to ~/.dmrc )

Ok so the location in ~/.dmrc is critical.

Yes, it's a standard/convention for DM's to store previous session information there.

The basic problem is we can handle file creations with a fixed name.  But not with a mis name.  We can allow the X login programs to create any content in the ~/ directory as xdm_home_t, but this forces us to allow the creation of any file if it does not exist.  From a security point of view it would be nice to only allow the creation of 

/home/[^/]*/\.dmrc.*	--	unconfined_u:object_r:xdm_home_t:s0
/home/[^/]*/\.cache/gdm(/.*)?	unconfined_u:object_r:xdm_home_t:s0
/home/[^/]*/\.xsession-errors.*	--	unconfined_u:object_r:xdm_home_t:s0

Of ~/.dmrc and .xsession-errors.

We could also setup a special directory under ~/.cache that would allow us to get the labels right.

IE Allow lightdm to write to 

/home/.cache/lightdm/dmrc

Then we could get it right.  We could theoretically allow a rename to ~/.dmrc.

But is there really a reason for .dmrc versus /home/.cache/lighttm/dmrc?

Isn't lightdm the only login manager that is going to use this?

All DM's I'm aware of support use of ~/.dmrc ,lightdm and kdm at least.  I wouldn't be surprised if gdm changed or deprecated it though.  (I'll go check...)

That said, I'm open to changing that to some other better known location if it makes selinux happier.

Hrm, even though gdm source comments seem to reference dmrc in several places, it seems it is indeed no longer used, in favor of querying accountsservice.  See also:
http://lxnay.wordpress.com/2011/09/13/yet-another-gnomegdm-3-idiocy-dropping-dmrc-support/
(if you get look beyond the trollish rants)

even though it's still indeed documented @
https://help.gnome.org/admin/gdm/stable/configuration.html.en

and for extra giggles, see also bug #617465

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

Description of problem:
This is a kvm VirtualMachine with rawhide installed [a few months ago] updated to latest rawhide a couple of days back.

The host is running F18 with 3.9.0-0.rc4.git0.2.fc20.x86_64

On bootup I do not see lightdm window manager. [just a blank screen]. There is a console message: [perhaps unrelated]?
 *ERROR* qxl too old, doesn't support client_monitors_config, use xf86-video-qxl in user mode

I can get lightdm to comeup after Alt-Ctrl-F2, Alt-Ctrl-F1

Once I login [to xfce] - I see this selinux message.

I tried deleting all selinux messages, run 'touch /.autorelabel', reboot - and login - and again see this message.

Hence reporting to bugzilla.

Additional info:
hashmarkername: setroubleshoot
kernel:         3.9.0-0.rc4.git0.2.fc20.x86_64
type:           libreport

Miroslav lets add a boolean to allow xdm_t to write xdm_home_t content in the users homedir.

Description of problem:
F19-Alpha-TC3-i386
QA:Testcase Partitioning on Software Raid
XFCE Default Setup
SEAlert at first login.

Additional info:
hashmarkername: setroubleshoot
kernel:         3.9.0-0.rc4.git0.1.fc19.i686.PAE
type:           libreport

reassigning to selinux-policy-targetted per comment #15

Description of problem:
initial login startup f19-tc3-alpha-i386

Additional info:
hashmarkername: setroubleshoot
kernel:         3.9.0-0.rc4.git0.1.fc19.i686.PAE
type:           libreport

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

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

Description of problem:
Booted XFCE live, Fedora 19 RC4.

Additional info:
hashmarkername: setroubleshoot
kernel:         3.9.0-0.rc6.git2.3.fc19.x86_64
type:           libreport

Just a "me too" and adding myself to cc.

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

Description of problem:
Initial startup xfce desktop install

Additional info:
hashmarkername: setroubleshoot
kernel:         3.9.0-0.rc6.git2.3.fc19.x86_64
type:           libreport

I am working on a fix.

Description of problem:
Just booting and logging in.

Additional info:
hashmarkername: setroubleshoot
kernel:         3.9.0-301.fc19.x86_64
type:           libreport

Please fix this ASAP. It is preventing the ability to shutdown via MATE.

>>> Please fix this ASAP. It is preventing the ability to shutdown via MATE.
Literally true and annoying to have the same 'problem' turning up again and
again. I did download some updates and there was peace and improvement in the 'Schrödinger Cat' -alpha-system for some days, only to find that Selinux
came up with exactly the same safety warning again today, back to zero so to say.
This Fedora 19 seems to turn to more contradictions than bearable for the 'patient' user, hope the final stable version will render something to live with and worth being labelled with such a promising name. 

Thanks for your time and efforts anyway for sure, one could guesss its not exactly an easy thing to cope with.

Description of problem:
Selinux guggests to do
# grep lightdm /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
to have access for lightdm standardly OKed.
So I drop the two command lines to my MATE-terminals shell, which seems to
be accepted and going OK, but the next day the same
Selinux alarm comes up again, cause lightdm standing in front
of some file, trying to access it, just as if nothing has changed
or as if the grep - semodule command did effect nothing at all.
It is totally ok with me to grant lightdm access but how to switch
that alarm/warning off? 

Additional info:
hashmarkername: setroubleshoot
kernel:         3.9.0-301.fc19.i686.PAE
type:           libreport

commit 755dfcf4a441d806c6fe57d5134950f847e90183
Author: Miroslav Grepl <mgrepl>
Date:   Mon May 6 11:27:35 2013 +0200

    Remove userdom_home_manager for xdm_t and move all rules to xserver.te directly
    Add new xdm_write_home boolean to allow xdm_t to create files in HOME dirs with xdm_home_t

Just building a new policy for testing.

Guys,
could you test it with

# rpm -Uvh http://kojipkgs.fedoraproject.org//packages/selinux-policy/3.12.1/41.fc19/noarch/selinux-policy-3.12.1-41.fc19.noarch.rpm http://kojipkgs.fedoraproject.org//packages/selinux-policy/3.12.1/41.fc19/noarch/selinux-policy-targeted-3.12.1-41.fc19.noarch.rpm

# setsebool xdm_write_home on

No error after performing the following

yum localupdate selinux-policy-3.12.1-41.fc19.noarch.rpm selinux-policy-targeted-3.12.1-41.fc19.noarch.rpm
touch /.autorelabel
setsebool -P xdm_write_home on
reboot

Thanks!

Great, thank you for testing.

Description of problem:
AVC on login via lightdm

Additional info:
hashmarkername: setroubleshoot
kernel:         3.9.0-301.fc19.x86_64
type:           libreport

Description of problem:
This always happens when lightdm starts.

Additional info:
hashmarkername: setroubleshoot
kernel:         3.9.0-301.fc19.x86_64
type:           libreport

Description of problem:
Booting Fedora-Live-XFCE-i686-19-Beta-TC3-1.iso

Additional info:
hashmarkername: setroubleshoot
kernel:         3.9.0-301.fc19.i686
type:           libreport

Discussed at 2013-05-08 freeze exception review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-05-08/f19beta-blocker-review-4.2013-05-08-16.00.log.txt . Accepted as a freeze exception issue as something that would be a blocker for a blocking desktop (affects only non-blocking Xfce and MATE spins afaik).

Description of problem:
Normal login to mate desktop

Additional info:
hashmarkername: setroubleshoot
kernel:         3.9.0-301.fc19.x86_64
type:           libreport

3.12.1-42 went stable, and boblfoot commented:

"This eliminated SELinux AVC Warning at startup for me in F19-Beta-TC3 Mate Desktop."

So I think we can mark this as closed. If anyone still has this AVC in Beta TC4, please comment. Thanks!

Yes, well done so far, after a couple of updates of the specific selinux packages,
no more alarming messages and getting nearer to a fedora 19 that's nice to have
and to work with. 

Only one thing, since I'm not really experienced with bugfiling reports:
The boot up process of Fedora 19 to the dm's login is pretty slow, noticeably slow. Puts me in a horrible wait state. Is there already a bug filed for this? How can I tell the developers, who put themselves in responsibility for a new Fedora 19 that makes the user happy in all aspects? Thanks.

Depends on the spin and login manager used.  If still speaking in the context of lightdm, filing bugs against it would likely be the best way forward.

(In reply to comment #45)
> The boot up process of Fedora 19 to the dm's login is pretty slow,
> noticeably slow. Puts me in a horrible wait state. Is there already a bug
> filed for this? How can I tell the developers, who put themselves in
> responsibility for a new Fedora 19 that makes the user happy in all aspects?
> Thanks.

Make sure you are running nodebug kernel or use 'slub_debug=-' on command line when debugging performance issues.

See https://fedoraproject.org/wiki/RawhideKernelNodebug for nodebug kernels.

We've been on release kernels in 19 for a while now. Klaus, sorry you're having trouble with slow startup; the first thing to look at is the output of 'systemd-analyze blame', which will show the time taken for startup of each of your services, and you should be able to see if one of them is the cause of the delay. Then you should be able to take appropriate action from there. If you need further help identifying the problem, please post on the test@ mailing list or in #fedora-qa on Freenode IRC.

Just got an SElinux AVC Warning which traced to this bug.

Was on F19-Beta-TC4-x86_64-XFCE-DE after running "yum update" which applied 175 updates from updates-testing and then rebooting.

How do I reopen as a new similiar problem must exist for xfce.

# rpm -q selinux-policy-targeted

Also please attach AVC msg. Thank you.

Description of problem:
Startup following yum update

Additional info:
reporter:       libreport-2.1.4
hashmarkername: setroubleshoot
kernel:         3.9.2-301.fc19.x86_64
type:           libreport

[bob@localhost ~]$ rpm -q selinux-policy-targeted
selinux-policy-targeted-3.12.1-44.fc19.noarch
[bob@localhost ~]$

Created attachment 748462 [details]
Output of AVC Message - 2013-05-15

Please run

# setsebool -P xdm_write_home 1

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