The .face file, used to store the user-pickable icon used by the
fast-user-switching capplet and gdm, cannot be seen be these programs as both
useradd and luseradd create home directories with permission 0700 instead of 0711.
This bug was noticed on a fresh install of fedora 9. I have not tested this on
This could also be issue with selinux. I noticed this behaviour by accident
after having turned selinux to permissive to test something on my system.
selinux enforcing shows no face icon
selinux permissive shows the face icon
after running "setenforce 0" and restarting GDM, still It does not display the
face icon. Home directory permission is 0700 as always has been (Fedora 8 GDM
shows the icon) so this does not look like selinux related or file permission
problems, at least on my installation
I also had problems with faces not showing up. Changed permission to 0711 for
the accounts on my box and now it works.
Is changing the permission to 0711 the acceptable fix for this bug?
yea, useradd should create dirs with 0711, I think. Not doing so breaks faces,
public_html directories, and other things.
but why my Fedora 8 has this home directory?
drwx------ 90 robert robert 4096 2008-05-23 14:50 robert
and the .faces file works on the old GDM (and I always have SELinux enabled)
Do not set your home directory to 711, that is a big security error, any user
will be able to read your files there if they know the name, they will not be
able to list them since the directory is not readable, but all files by a normal
user are created 664 by default
The GDM in F8 would read the faces as root from the daemon and tunnel the raw
image data through a socket to the login screen (which runs as user gdm).
We don't do that in F9.
0711 versus 0700 is a trade off. Note, though that the sensitive things that
have well known names (like private ssh keys, etc) are already locked down on
there own, and user files aren't listable with 0711.
well I consider even my .bash_profile something sensitive
Oops forgot to say this, I think something with PolicyKit must be done at the
GDM level to allow access to read those files, but setting home directories to
0711 is not acceptable in my opinion
I agree that the default should stay 0700 as is.
Okay, i've been out voted, moving back to gdm
Is there any word on whether this bug has a temporary/permanent fix?
Presuming you don't mind the looser permissions, comment 3 is a reasonable
A long term fix is to create a sticky directory (like tmp) as /var/lib/faces or
whatever. Users (and their program agents) can put their face icons in there.
Perhaps there should be a sticky /var/lib/user-options with a globally readable
directory for each user. If $HOME should be accessible to the user only, then
there needs to be some other globally readable directory for such configs.
(.face is similar in purpose to the old .plan and .project). It makes just as
much sense for users to set their umask to 007 or 077 and let $HOME be globally
readable. But whichever way you do it, there needs to be a per user globally
The same behavior in F10-beta
This bug has been triaged
*** Bug 452074 has been marked as a duplicate of this bug. ***
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.
More information and reason for this action is here:
*** Bug 473539 has been marked as a duplicate of this bug. ***
A better temporary workaround is
setfacl -m group:gdm:x ~
This at least only gives access to the gdm user.
Still broken in fedora 11 preview, with gdm-2.26.1-4
*** Bug 487920 has been marked as a duplicate of this bug. ***
Bumping version as this is still a bug.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.
More information and reason for this action is here:
Still broken in fedora 11 final, with gdm-2.26.1-10
(In reply to comment #26)
> Still broken in fedora 11 final, with gdm-2.26.1-10
ALSO: I successfully tried the "setfacl -m group:gdm:x ~" workaround on my laptop (which has been updated to F11-current from some of the betas. Yesterday I tried the same thing on my GF's laptop (F11 installed from final live CD) and I get
setfacl: /home/celesta: Die Operation wird nicht unterstützt
(-> operation is not supported)
and I really wonder why?
(In reply to comment #27)
> setfacl: /home/celesta: Die Operation wird nicht unterstützt
> (-> operation is not supported)
> and I really wonder why?
Sounds like acls are not enabled on that filesystem.
For ext3/4 you can change it on the filesystem directly:
tune2fs -o acl PATH-TO-FILESYSTEM-DEVICE
Or you can mount with -o acl (eg. in fstab).
(In reply to comment #28)
> Sounds like acls are not enabled on that filesystem.
I was wondering about that myself but can't check until in a few days. This is getting offtopic, but does anyone know if ACLs are supposed to be _off_ on a new F11 installation? If not there is another bug...
*** Bug 476760 has been marked as a duplicate of this bug. ***
This is very perplexing to me. My own account, which I created when I installed Fedora 10, shows my custom face; but my roommate's account which was created just recently does not show his. I've tried setting the file permissions on our home directories exactly the same (701) and it makes no difference. I am not using SELinux or ACL's.
The only thing I can think of is that gdm must be looking for the face icon somewhere other than ~/.face.
Any plan to fix this by default for F12?
Couldn't it just copy the image set in About Me to /var/gdb/faces/<username>?
Er, gdm/, not gdb/
Yea this got fixed for 2.28 which will be in F-12.
CLOSED CURRENTRELEASE is not used by Fedora, see:
Since I think this will not be backported, I changed the resolution to NEXTRELEASE.
Fedora Bugzappers volunteer triage team
Thanks to both of you.
The problem is still there in Fedora 14.
Note that /home has not been formatted and the home dirs have not ben created while installing Fedora 14.
I'm not sure it's the same problem. I su'd to gdm and I could access the .face file for my normal login.
# su -l -s /bin/bash gdm
# less /home/<user>/.face
It's a binary file but it did open...
I'm seeing this too, with F14. The home area permissions are drwx--x--x, no ACL, SELinux set to Permissive. Permissions on ~/.face are -rw-r--r-- and, as in Richard Shaw's case, the gdm user certainly can access the user's ~/.face file.
I encountered the same problem in F15... and after 5 months, I just found out about the work-around =/