System was up and running was the report was received. Sendmail is not set to be a demon. I have it set up as a cron job to run every hour as "sendmail -q".

I believe this is caused by your system running out of disk space.

I don't think that is the case.

$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg_workerbee-lv_root
                       25G  5.5G   18G  24% /
tmpfs                1001M  552K 1000M   1% /dev/shm
/dev/sda1             194M   58M  126M  32% /boot
/dev/mapper/luks-7cba58ab-8afa-4ad3-b0ab-40e535d83c83
                       46G   16G   28G  36% /home

The following are what these two capabilities could indicate.  They are not needed by sendmail on normal systems that I have seen.

/* Override resource limits. Set resource limits. */
/* Override quota limits. */
/* Override reserved space on ext2 filesystem */
/* Modify data journaling mode on ext3 filesystem (uses journaling
   resources) */
/* NOTE: ext2 honors fsuid when checking for resource overrides, so
   you can override using fsuid too */
/* Override size restrictions on IPC message queues */
/* Allow more than 64hz interrupts from the real-time clock */
/* Override max number of consoles on console allocation */
/* Override max number of keymaps */

#define CAP_SYS_RESOURCE     24

/* Allow configuration of the secure attention key */
/* Allow administration of the random device */
/* Allow examination and configuration of disk quotas */
/* Allow configuring the kernel's syslog (printk behaviour) */
/* Allow setting the domainname */
/* Allow setting the hostname */
/* Allow calling bdflush() */
/* Allow mount() and umount(), setting up new smb connection */
/* Allow some autofs root ioctls */
/* Allow nfsservctl */
/* Allow VM86_REQUEST_IRQ */
/* Allow to read/write pci config on alpha */
/* Allow irix_prctl on mips (setstacksize) */
/* Allow flushing all cache on m68k (sys_cacheflush) */
/* Allow removing semaphores */
/* Used instead of CAP_CHOWN to "chown" IPC message queues, semaphores
   and shared memory */
/* Allow locking/unlocking of shared memory segment */
/* Allow turning swap on/off */
/* Allow forged pids on socket credentials passing */
/* Allow setting readahead and flushing buffers on block devices */
/* Allow setting geometry in floppy driver */
/* Allow turning DMA on/off in xd driver */
/* Allow administration of md devices (mostly the above, but some
   extra ioctls) */
/* Allow tuning the ide driver */
/* Allow access to the nvram device */
/* Allow administration of apm_bios, serial and bttv (TV) device */
/* Allow manufacturer commands in isdn CAPI support driver */
/* Allow reading non-standardized portions of pci configuration space */
/* Allow DDI debug ioctl on sbpcd driver */
/* Allow setting up serial ports */
/* Allow sending raw qic-117 commands */
/* Allow enabling/disabling tagged queuing on SCSI controllers and sending
   arbitrary SCSI commands */
/* Allow setting encryption key on loopback filesystem */
/* Allow setting zone reclaim policy */

#define CAP_SYS_ADMIN        21

        if (atomic_read(&p->real_cred->user->processes) >=
                        task_rlimit(p, RLIMIT_NPROC)) {
                if (!capable(CAP_SYS_ADMIN) && !capable(CAP_SYS_RESOURCE) &&
                    p->real_cred->user != INIT_USER)
                        goto bad_fork_free;
        }

Looks like you were over the number of processes allowed and this is a result of checking to see if you are allowed to violate those limits (which it was not)

Not an SELinux problem.  Maybe the submitter knows s/he turned down the limits?  If not we may want to file with the sendmail people to see if they can explain how it got into this situation.

I may have done changed the limits when I was locking the system down. Remind me where I search in the configuration files to check how many proceseses I have set.

 (In reply to comment #6)
> I may have done changed the limits when I was locking the system down. Remind
> me where I search in the configuration files to check how many proceseses I
> have set.

AFAIK /etc/security/limits.d/90-nproc.conf or /etc/security/limits.conf

I don't see this problem in regular installations, please could you recheck?

Created attachment 440497 [details]
Required file

Created attachment 440498 [details]
Required file

Attached are the files are attached. I am not sure what is wrong with them. So I am not sure what changes I did how they differ from the installed originals.

I am not sure there is anything wrong with them.  Have you seen this AVC again?  it happened in May.  It might have been while your system was running out of processes.

If it has not happened since then, I would close this as insufficient data and you could reopen if it happens again.

I started up the SELinux Security Alerts program. It is reporting that it has seen this error 98 times since 8/12/2010 at 07:01:02 PM EST.:


Summary:

SELinux is preventing /usr/sbin/sendmail.sendmail "sys_admin" access .

Detailed Description:

[sendmail has a permissive type (system_mail_t). This access was not denied.]

SELinux denied access requested by sendmail. It is not expected that this access
is required by sendmail 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 FAQ
(http://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Please file a bug
report.

Additional Information:

Source Context                system_u:system_r:system_mail_t:s0-s0:c0.c1023
Target Context                system_u:system_r:system_mail_t:s0-s0:c0.c1023
Target Objects                None [ capability ]
Source                        sendmail
Source Path                   /usr/sbin/sendmail.sendmail
Port                          <Unknown>
Host                          workerbee
Source RPM Packages           sendmail-8.14.4-4.fc13
Target RPM Packages           
Policy RPM                    selinux-policy-3.7.19-33.fc13
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Plugin Name                   catchall
Host Name                     workerbee
Platform                      Linux workerbee 2.6.33.5-124.fc13.x86_64 #1 SMP
                              Fri Jun 11 09:38:12 UTC 2010 x86_64 x86_64
Alert Count                   98
First Seen                    Thu 12 Aug 2010 07:01:02 PM EDT
Last Seen                     Mon 23 Aug 2010 05:01:01 PM EDT
Local ID                      e8176318-7b67-461e-ac4f-afd0e151374b
Line Numbers                  

Raw Audit Messages            

node=workerbee type=AVC msg=audit(1282597261.528:504): avc:  denied  { sys_admin } for  pid=21638 comm="sendmail" capability=21  scontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tclass=capability

node=workerbee type=AVC msg=audit(1282597261.528:504): avc:  denied  { sys_resource } for  pid=21638 comm="sendmail" capability=24  scontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tclass=capability

node=workerbee type=SYSCALL msg=audit(1282597261.528:504): arch=c000003e syscall=56 success=yes exit=21639 a0=1200011 a1=0 a2=0 a3=7fb9f9101a90 items=0 ppid=21636 pid=21638 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=488 sgid=488 fsgid=488 tty=(none) ses=35 comm="sendmail" exe="/usr/sbin/sendmail.sendmail" subj=system_u:system_r:system_mail_t:s0-s0:c0.c1023 key=(null)

According to comment 5, maybe you are over number of allowed processes? From your limits.conf:

> * soft    nproc           64
> * hard    nproc           128

Please check the actual number of processes for the user under which you are running sendmail. Also please check the number of processes allowed for sendmail in your mc files (e.g. define(`confMAX_DAEMON_CHILDREN', `20')dnl for maximum 20 of processes).

Cron is setup to run as an hourly cron job. Its set to run as :

#!/bin/bash
/usr/sbin/sendmail -q

The number of processes seems to be 20.

sendmail.mc:dnl define(`confMAX_DAEMON_CHILDREN', `20')dnl

> sendmail.mc:dnl define(`confMAX_DAEMON_CHILDREN', `20')dnl

That do not limit the number of processes to 20! The first 'dnl' means the whole line is commented and not in effect.

Ok. I uncommented the line and cleared the selinux security alerts. We will have to wait and see if they come back.