Bug 112509 - login x display corrupted by bad read permissions on .gonf and .gconfd
login x display corrupted by bad read permissions on .gonf and .gconfd
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: GConf2 (Show other bugs)
9
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Mark McLoughlin
David Lawrence
http://www.redhat.com/archives/fedora...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-12-21 17:01 EST by George Watt
Modified: 2007-04-18 13:00 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-07-28 02:29:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description George Watt 2003-12-21 17:01:58 EST
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:
Comment 1 Mark McLoughlin 2004-07-28 02:29:59 EDT
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

Note You need to log in before you can comment on or make changes to this bug.