It also wants 'create' and 'write' access on the same ~/.dmrc* file.


[root@firefly ~]# grep dmrc /var/log/audit/audit.log | audit2allow -M dmrc
...


[root@firefly ~]# cat dmrc.te

module dmrc 1.0;

require {
	type user_home_t;
	type xdm_t;
	class file { write rename create };
}

#============= xdm_t ==============
allow xdm_t user_home_t:file { write rename create };

This is with lightdm-1.6.0-4.fc19.x86_64

This is strange...  I thought lightdm was using accountsservice now instead of managing .dmrc files.

# rpm -q --requires lightdm | grep acc
accountsservice

setsebool -P xdm_write_home 1

setroubleshoot usually gives you a helpful message if there's a Boolean you can toggle, but in this case, it just told me to create a local policy and/or open a bug.  I wonder why it didn't tell me about the xdm_write_home Boolean.

Should this be a bug against setroubleshoot instead?

Re-opening as a bug against lightdm: it should be using accountsservice instead of ~/.dmrc files.

lightdm supports both (for compatibility)

mgrepl, you mean this won't work out of the box?  What about kdm?  (it writes to ~/.dmrc too)

Or... should I toggle

setsebool -P xdm_write_home 1

in lightdm's %post scriptlet?

I just tried kdm and I didn't get any errors from SELinux Troubleshooter.  Only lightdm has a problem.  Both are running as xdm_t though.

Oh, it occurs to me that lightdm is running as unprivledged 'lightdm' user, so may expect writing to ~/.dmrc to ever work.

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

(In reply to comment #9)
> Or... should I toggle
> 
> setsebool -P xdm_write_home 1
> 
> in lightdm's %post scriptlet?

Yes, I would turn on the boolean this way.

 The problem is this allows xdm_t to create whatever with xdm_home_t in the /home directory. But it could mask some bugs and we have filename transitions for another cases.

Interestingly, I cannot seem to reproduce this problem, maybe because it's saving to accountsservice (for me).  I may have to dig into the code to see what's going on.

Though, as I mentioned in comment #11, since lightdm is unprivileged, expecting writes to ~/.dmrc may not ever work.

I take it back, I looked closer in audit.log and found the denial (seapplet failed to show it).

OK, sorry for the spam, but after looking at the code closer, I've confirmed lightdm saves to org.freedesktop.Accounts service first, then to ~/.dmrc

So, an alternative fix here is to simply drop the second step of writing to ~/.dmrc (since it would appear no one else but kdm supports that anymore).

Any comments/objections to implementing that?

lightdm-1.6.0-5.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/lightdm-1.6.0-5.fc19

Package lightdm-1.6.0-5.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing lightdm-1.6.0-5.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-8422/lightdm-1.6.0-5.fc19
then log in and leave karma (feedback).

Discussed at 2013-05-20 freeze exception review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-05-20/f19beta-blocker-review-7.2013-05-20-16.07.log.txt . Accepted as an FE issue: lightdm is only used for non-blocking desktops so this carries little risk of causing a blocker bug, and the fix seems sensible and safe for the non-blocking desktops. The bug is superficial but very visible for users of the spins that use lightdm, which is at least LXDE, Xfce and MATE that I know of, so fixing it seems worthwhile.

Description of problem:
login to MATE DE

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

lightdm 1.6.0-5 does not solve the issue..

[dan@localhost ~]$ getsebool xdm_write_home
xdm_write_home --> off

[root@localhost dan]# rpm -qa |grep lightdm
lightdm-gtk-1.5.1-3.fc19.x86_64
lightdm-1.6.0-5.fc19.x86_64
lightdm-gobject-1.6.0-5.fc19.x86_64

Hrm, is the scriptlet I used doesn't work reliably:

%post
# tweak selinux to work out-of-the-box
# see also: http://bugzilla.redhat.com/963238
if [ "`getsebool xdm_write_home 2>/dev/null`" == 'xdm_write_home --> off' ] ; then
  setsebool -P xdm_write_home on &> /dev/null ||:
fi
...

then I might just resort to patching out the code that touches ~/.dmrc per comment #16

rex: that seems like a much better option to me. Actually, I thought that was what -5.fc19 did already.

Package lightdm-1.6.0-6.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing lightdm-1.6.0-6.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-8422/lightdm-1.6.0-6.fc19
then log in and leave karma (feedback).

Package lightdm-1.6.0-8.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing lightdm-1.6.0-8.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-8422/lightdm-1.6.0-8.fc19
then log in and leave karma (feedback).

Description of problem:
SELinux blocked lightdm write process in home folder

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

this is still happening with -8 in beta rc4. did the build somehow get messed up and not actually include the fix to stop writing/reading/caring about .dmrc?

Not my best week.  confirmed -8 botched not including the quick-n-dirty patch I made. :(

http://pkgs.fedoraproject.org/cgit/lightdm.git/tree/lightdm-1.6.0-no_dmrc_save.patch?h=f19



-9 on the way.

Package lightdm-1.6.0-9.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing lightdm-1.6.0-9.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-8422/lightdm-1.6.0-9.fc19
then log in and leave karma (feedback).

I am getting selinux alerts even with -9. I can post the sealert messages if needed.

What does

# getsebool xdm_write_home

mgrepl: it doesn't really matter, because what -9 is supposed to do is not write .dmrc files at all. It's not meant to flip the boolean.

nonamedotc: are you sure the alerts are from after updating to -9, not just stale alerts from before you updated? Do they still reference the .dmrc files?

mgrepl: My F19 computer is at home. I will post the output later today.

adamw: Yes. I verified the lightdm version and also timestamp before posting my comment here. So, I am confident that the version is right. I also rebooted twice and {looged out/logged in} twice to make sure I am infact using the correct version. But yeah, I can definitely check again.

What weird (for me) though, is I just did a new F19 netinstall on VM. No sealert notification on the VM. So, I do not know what's going on.

lightdm-1.6.0-8.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

OK. Sorry folks.  -9 does fix the issue. It was a mistake as adamw pointed out. I rebooted multiple times alright and got multiple alerts. But, all of them were just before updating. I checked the timestamps on yum history, sealert and using last now, it turns out, I was wrong my two minutes (22:59 vs 23:01)! 

Sorry again people!

sorry for bothering your circles, but lightdm-1.6.0-8.fc19 does not fix this

and while the Bodhi url has ...-9.fc19 the latest build available is -8

here are my details, just after fresh start, note the dates:

SELinux is preventing /usr/sbin/lightdm from create access on the file /home/kvolny/.

*****  Plugin restorecon (99.5 confidence) suggests  *************************

If you want to fix the label. 
/home/kvolny/ default label should be default_t.
Then you can run restorecon.
Do
# /sbin/restorecon -v /home/kvolny/

*****  Plugin catchall (1.49 confidence) suggests  ***************************

If you believe that lightdm should be allowed create access on the  file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep lightdm /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:xdm_t:s0-s0:c0.c1023
Target Context                system_u:object_r:user_home_t:s0
Target Objects                /home/kvolny/ [ file ]
Source                        lightdm
Source Path                   /usr/sbin/lightdm
Port                          <Neznámé>
Host                          (removed)
Source RPM Packages           lightdm-1.6.0-8.fc19.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.12.1-47.fc19.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux kvolny.usersys.redhat.com
                              3.9.4-300.fc19.x86_64 #1 SMP Fri May 24 22:17:06
                              UTC 2013 x86_64 x86_64
Alert Count                   1
First Seen                    2013-06-03 09:19:40 CEST
Last Seen                     2013-06-03 09:19:40 CEST
Local ID                      f166db46-ef57-44c6-a0ec-4e2178de6708

Raw Audit Messages
type=AVC msg=audit(1370243980.47:509): avc:  denied  { create } for  pid=675 comm="lightdm" name=".dmrc.PAE4XW" 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(1370243980.47:509): arch=x86_64 syscall=open success=no exit=EACCES a0=2558e30 a1=c2 a2=1b6 a3=1 items=1 ppid=1 pid=675 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=CWD msg=audit(1370243980.47:509): cwd=/

type=PATH msg=audit(1370243980.47:509): item=0 name=/home/kvolny/ inode=28835842 dev=fd:00 mode=040700 ouid=1000 ogid=1000 rdev=00:00 obj=unconfined_u:object_r:user_home_dir_t:s0

Hash: lightdm,xdm_t,user_home_t,file,create

lightdm-1.6.0-9.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/lightdm-1.6.0-9.fc19

Description of problem:
may be this happend after visiting site porevo.info

Additional info:
reporter:       libreport-2.1.4
hashmarkername: setroubleshoot
kernel:         3.9.4-300.fc19.i686.PAE
type:           libreport

Description of problem:
Logged in with two users, don't know which one caused this.

Additional info:
reporter:       libreport-2.1.4
hashmarkername: setroubleshoot
kernel:         3.9.4-300.fc19.x86_64
type:           libreport

Description of problem:
Fresh Install of F19 i386 xfce Final - TC1

Additional info:
reporter:       libreport-2.1.4
hashmarkername: setroubleshoot
kernel:         3.9.4-300.fc19.i686.PAE
type:           libreport

lightdm-1.6.0-9.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.