GDM problems: gdm-binary

[Daniel B. Thurman]

Due to reasons of my /usr space partition running out of
room, I had tar-copied my /usr/share directory into different
partition, deleted the contents of /usr/share, changed the
fstab to mount the /share partition /usr/share. Because there
is a filesystem change, I believed an autorelabel is necessary
to ensure that all of the selinux tags are properly labeled.

Fortunately, after a reboot, I was able to log into my system,
but not without some problems.  The following is a list of issues
that cropped up during the ordeal:

When I rebooted after changing /usr/share:

1. The normal linux textscreen data appears
2. udev
3. A black screen with quick X11 black/white "watch" cursor popped up
   then it disappeared quickly, like a flash.
   [NOTE:
      Here, you would normally see a gnome cursor with a blue spinner
      then a gui screen showing the progress bar on the loading of services
   ]
4. Then it switched back into text mode showing (among other things),
   the last 4 lines:
     a. Remounting / rw
     b. Mounting local filesystems 
     c. Doing local filesystem quotas
     d. Enabling /etc/fstab swap
        [text-cursor sits waiting] and less than a minute later,
        (Maybe services are being loaded during this waiting period
         but you cannot know or see it, can only assume it is or after
         logging in.  Turns out that services are loaded successfully.
         It is interesting to note that loading of services are VERY
         QUICK compared to watching the gui screen on service loading
         progress.  Interesting.)
5. The gui login screen pops up.
6. I am able to log in as myself as a normal user.
7. Many sealert messages popped up, most of it showing GDM, sendmail,
   clamav, spamassassin avc denial errors.
8. After hours trying restorecon in progression:
   a. /var/run/{clamav-milter,clamd.clamdsvc} directory
      i.   restorecon -vR on these directries did not work, sealerts kept coming
      ii.  Changed directory permissions to 750, owners to [owner]:root
           Problem solved.  sealert stopped.
   b. SpamAssassin
      i. After many attempts to fix this, I finally tried:
         rm -fr ~[users]/.spamassasin directories
         Problem solved.  selalerts stopped for spamassassin.
         [NOTE: ~[user]/.spamassassin is automatically recreated.]
9. Now, tying to solve gdm-binary problems:
   a. Remove and reinstall GDM.
      It fixed a /var/log/messages error entry that showed gdm-binary was
      segfaulting, but it did not restore the missing services-loading gui
      screen and there are still problems with gdm-binary and sealerts.

   b. Grepping for GDM in the /var/log/messages file reveals:

      + Dec 19 07:42:59 linux setroubleshoot: #012 SELinux is preventing gdm-binary (xdm_t) "signal" to <Unknown> (mono_t).#012     For complete SELinux messages. run sealert -l 966ed3a0-cb89-41cc-8eff-7168d263b538
      + Dec 19 07:47:17 linux gdm-binary[2998]: (null): cannot open shared object file: No such file or directory

      Running: sealert -l 966ed3a0-cb89-41cc-8eff-7168d263b538
      ========================================================
      Summary
          SELinux is preventing gdm-binary (xdm_t) "signal" to <Unknown> (mono_t).

      Detailed Description
          SELinux denied access requested by gdm-binary. It is not expected that this
          access is required by gdm-binary and this access may signal an intrusion
          attempt. It is also possible that the specific version or configuration of
          the application is causing it to require additional access.

      Allowing Access
          You can generate a local policy module to allow this access - see
          http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385 Or you can disable
          SELinux protection altogether. Disabling SELinux protection is not
          recommended. Please file a http://bugzilla.redhat.com/bugzilla/enter_bug.cgi
          against this package.

      Additional Information        

      Source Context                system_u:system_r:xdm_t:s0-s0:c0.c1023
      Target Context                system_u:system_r:mono_t:s0-s0:c0.c1023
      Target Objects                None [ process ]
      Affected RPM Packages         
      Policy RPM                    selinux-policy-3.0.8-64.fc8
      Selinux Enabled               True
      Policy Type                   targeted
      MLS Enabled                   True
      Enforcing Mode                Enforcing
      Plugin Name                   plugins.catchall
      Host Name                     linux.cdkkt.com
      Platform                      Linux linux.cdkkt.com 2.6.23.8-63.fc8 #1 SMP Wed
                                    Nov 21 18:51:08 EST 2007 i686 i686
      Alert Count                   2
      First Seen                    Wed Dec 19 07:42:32 2007
      Last Seen                     Wed Dec 19 07:42:48 2007
      Local ID                      966ed3a0-cb89-41cc-8eff-7168d263b538
      Line Numbers                  

      Raw Audit Messages            

      avc: denied { signal } for comm=gdm-binary pid=3060
      scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tclass=process
      tcontext=system_u:system_r:mono_t:s0-s0:c0.c1023
      ======================================================

    c. I am thinking of removing and reinstalling mono since it seems
       that mono problems are showing in the above sealert trace?

Note: 
    1. Tar (with --xattrs) and cp -a does not preserve the selinux tags
       at all.  It seems broken.  It is possible, but not verified, that
       maybe the copy-over of some files got corrupted?
    2. It seems that autorelabeling does not completely relabel and restore
       selinux tags faithfully?


No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.503 / Virus Database: 269.17.5/1190 - Release Date: 12/19/2007 7:37 PM