GDM problems: gdm-binary

[Daniel B. Thurman]

Paul Howarth wrote:
>"Daniel B. Thurman" <dant at cdkkt.com> wrote:
>
>> Paul Howarth wrote:
>> >Daniel B. Thurman wrote:
>> >> Daniel B. Thurman wrote:
>> >>> 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.
>> >
>> >...
>> >
>> >> I found some more problems with selinux tags and somehow it
>> >> is not able to label files after a autorelabel which I was
>> >> hoping it would fix but does not.  Can someone please tell
>> >> me how to fix these problems?
>> >> 
>> >>>From /var/log/audit log:
>> >> ============================================================>>
>> >> type=SYSCALL msg=audit(1198252520.322:187): arch at 000003 
>> >syscall2 success=no exit=-13 a0=3 a1¿c093c0 a2·f6d31c 
>> >a3=0 items=0 ppid'00 pid667 auidB94967295 uid=0 gid=0 
>> >euid=0 suid=0 fsuid=0 egidQ sgidQ fsgidQ tty=(none) 
>> >comm="sendmail" exe="/usr/sbin/sendmail.sendmail" 
>> >subj=system_u:system_r:sendmail_t:s0 key=(null)
>> >> type=AVC msg=audit(1198252520.322:187): avc:  denied  { 
>> >connectto } for  pid667 comm="sendmail" 
>> >path="/var/run/spamass-milter/spamass-milter.sock" 
>> >scontext=system_u:system_r:sendmail_t:s0 
>> >tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket
>> >> type=AVC msg=audit(1198252486.805:186): avc:  denied  { 
>> >connectto } for  pid647 comm="sendmail" 
>> >path="/var/run/spamass-milter/spamass-milter.sock" 
>> >scontext=system_u:system_r:sendmail_t:s0 
>> >tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket
>> >
>> >This looks remarkably like this bug report:
>> >https://bugzilla.redhat.com/show_bug.cgi?idB5958
>> >
>> >You seem to have the socket labelled as initrc_t rather than 
>> >spamd_var_run_t, but I don't know why this should happen.
>> >
>> >Can you post the output of:
>> >$ ls -lZd /var/run
>> 
>> drwxr-xr-x  root root system_u:object_r:var_run_t:s0   /var/run
>> 
>> >$ ls -laZ /var/run/spamass-milter
>> 
>> drwxr-x---  sa-milt root    system_u:object_r:spamd_var_run_t:s0 .
>> drwxr-xr-x  root    root    system_u:object_r:var_run_t:s0   ..
>> srwxr-xr-x  sa-milt sa-milt system_u:object_r:spamd_var_run_t:s0
>> spamass-milter.sock
>
>This all looks normal so I guess you're not getting the AVCs from
>spamass-milter anymore?
>
>> >>From /var/log/messages log: (Note that all of these errors are
>> >> coming from the /usr/share that is mounted from a drive partition
>> >> while all in / is in its own partition, but /usr/share)
>> >> ============================================================>> Dec
>> >> 21 07:50:21 linux kernel: audit(1198252191.457:5): avc:  
>> >denied  { search } for  pid69 comm="rhgb" name="share" 
>> >dev=sda2 ino2929 scontext=system_u:system_r:rhgb_t:s0 
>> >tcontext=user_u:object_r:default_t:s0 tclass=dir
>> >
>> >Try unmounting /usr/share, labelling the now-empty directory as
>> >mnt_t,
>> 
>> How do I do this, please?
>
># umount /usr/share
># chcon -t mnt_t /usr/share
>
>> >remounting /usr/share and labelling the mounted directory as usr_t.
>
># mount /usr/share
># chcon -t usr_t /usr/share
>
>Paul.

Notes:
1: Just to make sure that I have noted it here, the latest
   yum updates have been applied.
2: The mounting of LABEL=/share to /usr/share appears as a
   drive on the desktop, unlike /usr, which does not appear.
   This is quite annoying. Why is that it appears on the desktop?

1. Have have done what you have asked, above.
2. restorecon -vvR /usr
   <no corrections were made>
3. clamav-milter:
   + was never started at boot. Logs show a permission problem with clamav.log
   + deleted: /var/log/clamav-milter/clamav.log
   + service clamav-milter start
     <no more sealert permissions problems, it started up!>
     [perhaps, the problem here is that an existing log file from
      a previous startup, is no longer accepted and fails on the
      next reboot unless clamav-milter service is shutdown, the
      log file is deleted, before rebooting.  This has been verified.]
4. spamass-milter:
   + The spamass-milter.sock orignally when created at reboot shows:
     srwxr-xr-x  sa-milt sa-milt system_u:object_r:spamd_var_run_t:s0 spamass-milter.sock

     BUT, when restarting spamassassin, it shows a different user context:
     drwxr-x---  sa-milt root    system_u:object_r:spamd_var_run_t:s0 .
     drwxr-xr-x  root    root    system_u:object_r:var_run_t:s0   ..
     srwxr-xr-x  sa-milt sa-milt unconfined_u:object_r:spamd_var_run_t:s0 spamass-milter.sock
     ----------------------------^^^^^^^^^^^^

   + chcon -u system_u spamass-milter.sock
     <has no effect, sealert continues>
   + chcon -t initrc_t spamass-milter.sock
     <permission denied, even as root user>

5. I still have unresolved issues with the others:
   rhgb, xorg, ifconfig, xdm-server

Any ideas, anyone?


No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.516 / Virus Database: 269.17.6/1192 - Release Date: 12/21/2007 1:17 PM