[PLUG] It just happened again (Resolved)

John Jason Jordan johnxj at comcast.net
Mon Dec 7 01:37:58 UTC 2009


On Sun, 06 Dec 2009 15:39:54 -0800
Dale Snell <ddsnell at verizon.net> dijo:

>On Sun, 06 Dec 2009 11:30: -320800
>John Jason Jordan <johnxj at comcast.net> wrote:
>
>> Thanks for all the suggestions. I finally nailed it.
>> 
>> The ~/.local-original/share/applications folder for the new user had
>> only two files. My ~/local/share/applications folder has many
>> entries. I don't know what they do. Some appear to be part of the
>> Applications menu, but others clearly are not. And I also have
>> launchers in Applications that are not reflected in a file in this
>> folder. 
>> 
>> However, I was especially interested in a file called
>> metacity.desktop. I noted that the new user's original folder did not
>> contain this file. I tried to rename it, but Nautilus would not let
>> me. I certainly own the file and have rw permissions for it, but
>> Nautilus just wouldn't let me. No matter, as root from the command
>> line I renamed it metacity.desktop.old. Then I rebooted. And after
>> logging in metacity launched as it is supposed to. Everything else
>> seems to be working normally.
>> 
>> I have no idea what rogue process created this file.
>> 
>> It is a text file that can be opened with Gedit. Looking at the
>> contents I see nothing that says "don't launch metacity for this
>> user." 
>> 
>> If any of the Gnome users on this list have such a file, it would be
>> interesting to compare notes. I feel an obligation to file a bug
>> report, but I in order to make the bug report useful I need to figure
>> out what is the purpose of the file, what created it, and where it
>> went wrong.
>> 
>
>John,
>
>I do have the ~/.local/share/applications folder, and the metacity file
>is in it.  It's a simple text file.  The contents are:
>
>[Desktop Entry]
>Version=1.0
>Encoding=UTF-8
>Name=Metacity
>Type=Application
>...
><many lines of the form "Name[<language-specifier>]=Metacity">
>...
>Exec=metacity
>NoDisplay=true
>X-GNOME-WMSettingsModule=metacity
>X-GNOME-WMName=Metacity
>X-GnomeWMSettingsLibrary=metacity
>X-GNOME-Bugzilla-Bugzilla=GNOME
>X-GNOME-Bugzilla-Product=metacity
>X-GNOME-Bugzilla-Component=general
>X-GNOME-Autostart-Phase=WindowManager
>X-GNOME-Provides=windowmanager
>X-GNOME-Autostart-Notify=true
>Name[en_US]=Metacity
>
>Nautilus shows the filename as "Metacity", but ls shows it as
>metacity.desktop (note the capitalization).  Changing the name from the
>command line (mv metacity.desktop metacity.desktop.orig) changed the
>name as shown by ls.  Nautilus, however, still showed it as Metacity.
>Changing the name with Nautilus, to Metacity.orig, showed the name
>changed there.  Just to be stubborn, ls showed the name as
>metacity.desktop.orig.  A little digging showed what is likely the
>reason.
>
>The last line of the file is "Name[en_US]=Metacity".  If I change the
>filename using Nautilus, that line changes to
>"Name[en_US]=Metacity.orig".  The actual filename, as shown by ls, does
>not change.  It seems pretty obvious that this line is what Nautilus is
>reporting as the filename, at least on my system.
>
>Now, as to why Nautilus didn't want to let you change the name of your
>file, I'm not sure.  Check the SELinux context for the file, that may
>be a problem.  For that matter, check the context for the parent
>directory.  I've had trouble occasionally where I couldn't change a
>file, even as root.  The security context turned out to be the
>trouble.  Here are the directory listings from my system:
>
>[dales at valeron applications]$ ls -d --context ../applications
>drwxr-xr-x  dales dales unconfined_u:object_r:user_home_t:s0 ../applications
>[dales at valeron applications]$ ls --context metacity.desktop
>-rw-rw-r--  dales dales unconfined_u:object_r:user_home_t:s0 metacity.desktop
>
>Now that I think about it, SELinux contexts could be a problem waiting
>to bite you.  If you're bringing files into Fedora from another distro,
>they almost certainly don't have the right security contexts, assuming
>that they have any at all.  Nautilus can set the contexts for you.
>Move to your /home directory and right-click on your user directory.
>Select "Properties" and select the "Permissions" tab.  Make sure that
>your folder and file permissions are set correctly (they probably
>are).  Then, at the bottom of the panel, you'll see a line "SELinux
>Contexts" and a string widget.  Make sure the settings are right
>(again, they probably are, but if not see mine, above), click
>the "Apply Permissions to Enclosed Files" button, and you should be
>good to go.

The string widget on my Nautilus is just a drop-down, but "User home directory"
is what it was set to. I did click on the Apply Permissions to Enclosed Files
button, on general principles.

I have brought in only a handful of config files from other distros
- .openoffice.org, .scribus, .rhythmbox, and the like. But no config files
 relative to the desktop or OS.

Having said that, I have copied several dozen GB of data from my old Ubuntu
disk. These are just data files. The interesting thing is that I did so by
dragging and dropping with Nautilus. And I got constant error messages about
lack of permission.

The interesting thing is that it was always certain kinds of files, but not
always. For example, when dragging a folder containing files for books on Mani
and Kim that I did for a PSU professor, I could copy some PDF files, but not
others; some TIFF images, but not others, etc. I kept looking for a pattern,
e.g., were the non-allowed PDFs files that I did not create myself? But there
was no obvious pattern.

>That said, I *strongly* suggest reading up on SELinux.  I found the
>man pages to be dry and rather rough going, but their info is good to
>have, since Fedora uses SELinux as part of its security setup.
>O'Reilly has a book on SELinux which is easier reading than the Linux
>man pages.
>
>Anyway, I hope that helped.

It does, although it gives me a lot of work to do. :(



More information about the PLUG mailing list