Bug 522513

Not sure why krootimage is trying to write files under /etc.

The should be under /var some where.

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

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

kdm's config files are under, /etc/kde/kdm, I presume this user was running systemsettings (as root, or with elevated privs) to configure kdm theme, background, etc...

Reporter, can you clarify if this is the case or not?

I think I've found the problem, although I haven't yet tried to fixed it.

What I'd done was create a directory under / called /Wallpapers, and placed a lot of pictures (mostly JPEG) in it. But, since I run SELinux in "permissive" mode, I didn't think about changing the security context of those pictures. Thus I get "access denied" messages when the KDE (or KDM) process (like 'krootimage") uses (or tries to use) the image as a background.

Anyhow, I just posted several "bugs" related to this problem, but - if I'm correct about the cause - you should ignore/close them. (They all relate to either "krootimage" or "backgroundrc.") I had just entered the last "bug" report when this idea occurred to me.

I'm going to see if I can relabel the files in the directory now, and, if that fixes this, I'll add another comment.

BTW, does the suggested fix (allow xdm_t etc_t:file setattr;) in the first post  necessarily imply that the krootimage program (which, I think, is setting the background image for the KDM login screen) was trying to write to /etc?

(In reply to comment #4)
> kdm's config files are under, /etc/kde/kdm, I presume this user was running
> systemsettings (as root, or with elevated privs) to configure kdm theme,
> background, etc...
> 
> Reporter, can you clarify if this is the case or not?  

Since the KDM process resets the "background" image location in the configuration file in /etc/kde/kdm, and since I've told KDM to randomly select a background image from the /Wallpapers directory on every boot, and every minute thereafter, that file does get changed every time I boot the system.

So, no, I wasn't using "system settings," but, yes, the configuration file was being changed, and that change is automatically made at every login.

I would argue that this should be in /var/lib/kdm not /etc/kde/kdm since /etc is supposed to be readonly.

chcon -R -t xdm_var_lib_t /etc/kde/kdm

WIll fix your problem.

Alright, it would appear then, that we can't support kdm's slideshow feature out of the box (ie, it requires unacceptable policy changes).  

You're welcome to adjust your local selinux policy to suit your own needs, of course.

Looking more into this,

 matchpathcon /etc/kde/kdm/backgroundrc 
/etc/kde/kdm/backgroundrc	system_u:object_r:xdm_var_run_t:s0


So the problem is the lock file can not be created.  So if the backgroundrc file was moved to a different location like /var/lib/kdm it would work fine.

Or if we want to keep it in the /etc directory can we move it to a subdir of /etc/kde/kdm

I'll take a closer look, to see which approach works better, thanks.

Well the first suggestion is no good since It allows xdm_t to write Xsession which can influence the login session.

Those lock files are apparently new in KDE 4.3, to prevent some race conditions in kconfig. I guess that's why this hasn't come up earlier.

Well it should still not be attempting to write to /etc/.  /etc/ is supposed to be a read/only file system.   If this stuff is moved to /var/lib/kdm, SELinux control will get much easier and you guys would work better in systems with locked down /etc partitions.  If I give kdm the ability to write to this directory and the contents.  The tool could also overwrite XSession which would allow the tool to manipulate the way other peoples logins.

Why am I paranoid about the login program?  Well login programs can be run by anyone, login programs are getting quite extensive with thousands of lines of code for stuff like networking, and Assistive Controls.  If a bug shows up in one of these a cracker could walk up to a machine and do evil without having to crack into a machine.

Rex is this something we want to fix locally and then try and upstream patches or just bump upstream entirely?

-- 
Steven M. Parrish - KDE Triage Master
                  - PackageKit Triager
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

It's a problem of our own doing, since this is usually at /usr/share/config/kdm and we moved it to /etc/kde/kdm.

kdmrc indeed has
BackgroundCfg=/etc/kde/kdm/backgroundrc

So it looks like we can move this to (something like) /var/lib/kdm alright.  I'll test it out.

kde-settings %changelog
* Sat Jan 30 2010 Rex Dieter <rdieter> 4.4-10
- move /etc/kde/kdm/backgroundrc => /var/lib/kdm/backgroundrc (#522513)
- own /var/lib/kdm (regression, #442081)

moving this config file within a release is painful and a bit risky, not sure we want to go there.

Are you sure this is a good idea? IMHO config files should really be in /etc, not /var.

I think so in this case.  backgroundrc default location happens to be /var/lib/kdm (according to kdm's sources), it only ended up in /etc/kde/kdm due to our previously customized
BackgroundCfg=
directive

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

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