From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 Description of problem: I created a new user (in group users; one other user in group users) whose files I wanted everybody to be able to read. Not fully understanding what the default umask was already doing, I cd'd one level above the user's home directory and executed "chmod -R a+r username". When this user then logged in, the x display was completely corrupted, exactly as described at the URL given above, and exactly the same error messages show up in the .xsession-errors file. I finally figured out that the problem was the group and other read privledges on the .gconf and .gconfd directories. Logging in as root and then "su - username"'ing to the users home directory (no problem doing that), I then went "chmod -R go-r .gconf*", rebooted the computer just to be sure, and the problem went away. I noticed that some directories had not been changed by my original stupid use of chmod, .gnome-private for example, so it seems to me that .gconf and .gconfd should be similarly protected from this kind of mistake. The consequences are certainly disasterous. Version-Release number of selected component (if applicable): GConf2-2.2.0-1.i386.rpm How reproducible: Always Steps to Reproduce: 1.chmod -R a+r ./username from just above username home directory 2.log out and then try to log back in. 3. Actual Results: corrupted x display Expected Results: .gconf and .gconfd should not be allowed to have their user-only read permissions changed. Additional info:
I can't reproduce this with Fedora Core 2. Looks like its fixed now with that we're using local locks. Steps to try and reproduce: 1) Add users test, log in as test, log out 2) chmod -R a+r /home/test/.gconf /home/test/.gconfd 3) log in as test (no problem), log out 4) chmod -E a+r /home/test 5) log in as test, no problems