Request Tracker 3

[Kanwar Ranbir Sandhu]

Hello Everyone,

Has anyone attempted to run RT3 (3.2.2) on a FC3 system?  I'm running
into a bunch of selinux errors, and I'm having problems resolving the
issue: I'm just not very familiar with selinux.

Here's the error in /var/log/httpd/error_log:

---start---

[Sun Jan 30 19:42:14 2005] [notice] suEXEC mechanism enabled
(wrapper: /usr/sbin/suexec)
[Sun Jan 30 19:42:17 2005] [notice] Digest: generating secret for digest
authentication ...
[Sun Jan 30 19:42:17 2005] [notice] Digest: done
[Sun Jan 30 19:42:17 2005] [notice] LDAP: Built with OpenLDAP LDAP SDK
[Sun Jan 30 19:42:17 2005] [notice] LDAP: SSL support unavailable
[Sun Jan 30 19:42:17 2005] [notice] FastCGI: process manager initialized
(pid 669)
[Sun Jan 30 19:42:17 2005] [warn] FastCGI: server
"/var/www/rt/bin/mason_handler.fcgi" started (pid 670)
[Sun Jan 30 19:42:17 2005] [notice] mod_python: Creating 4 session
mutexes based on 256 max processes and 0 max threads.
[Sun Jan 30 19:42:19 2005] [notice] Apache/2.0.52 (Fedora) configured --
resuming normal operations
[Sun Jan 30 19:42:22 2005] [warn] FastCGI: server
"/var/www/rt/bin/mason_handler.fcgi" started (pid 679)
[Sun Jan 30 19:42:27 2005] [warn] FastCGI: server
"/var/www/rt/bin/mason_handler.fcgi" started (pid 681)
[Sun Jan 30 19:42:32 2005] [warn] FastCGI: server
"/var/www/rt/bin/mason_handler.fcgi" started (pid 682)
Log file /var/log/rt.log couldn't be written or created.
 RT can't run. at /var/www/rt/lib/RT.pm line 204.

---end---

And here's what's output to /var/log/messages while that's going on:

---start--

avc:  denied  { getattr } for  pid=681 exe=/usr/bin/perl path=/var/log
dev=dm-5 ino=129025 scontext=root:system_r:httpd_sys_script_t
tcontext=system_u:object_r:var_log_t tclass=dir

avc:  denied  { ioctl } for  pid=693 exe=/usr/bin/perl
path=/var/log/httpd/error_log dev=dm-5 ino=129070
scontext=root:system_r:httpd_sys_script_t
tcontext=system_u:object_r:httpd_log_t tclass=file

avc:  denied  { read } for  pid=693 exe=/usr/bin/perl name=tmp dev=dm-3
ino=12 scontext=root:system_r:httpd_sys_script_t
tcontext=system_u:object_r:tmp_t tclass=lnk_file

---end---

Ummm..not quite sure how to interpret that.  But, it looks like selinux
doesn't like the context of /var/log/rt.log, which currently is:

-rw-r--r--  root     rt
system_u:object_r:httpd_log_t    /var/log/rt.log

And for /var/log/http (as well as for all files within):

drwx------  root     root     system_u:object_r:httpd_log_t

I could just turn off selinux, but seeing as how I've managed to run
SugarCRM and Mambo on the same box, RT3 should work as well.

Thanks in advance.

Regards,

Ranbir
-- 
Kanwar Ranbir Sandhu
Linux Consultant
Systems Aligned Inc.
www.systemsaligned.com

[Colin Walters]

On Sun, 2005-01-30 at 20:06 -0500, Kanwar Ranbir Sandhu wrote:
>  Hello Everyone,
>  
>  Has anyone attempted to run RT3 (3.2.2) on a FC3 system?  I'm running
>  into a bunch of selinux errors, and I'm having problems resolving the
>  issue: I'm just not very familiar with selinux. 
Have you seen the Fedora Apache/SELinux guide?
http://fedora.redhat.com/docs/selinux-apache-fc3/

>  avc:  denied  { getattr } for  pid=681 exe=/usr/bin/perl
> path=/var/log
>  dev=dm-5 ino=129025 scontext=root:system_r:httpd_sys_script_t
>  tcontext=system_u:object_r:var_log_t tclass=dir 
Hmm.  Given that we allow access to httpd_log_t which is in the default
configuration a subdirectory of var_log_t, I'm surprised that this
access is not allowed.  Ideally though the app should not need this.

>  avc:  denied  { ioctl } for  pid=693 exe=/usr/bin/perl
>  path=/var/log/httpd/error_log dev=dm-5 ino=129070
>  scontext=root:system_r:httpd_sys_script_t
>  tcontext=system_u:object_r:httpd_log_t tclass=file 
This one is probably harmless; I think perl does an ioctl even on
regular files in many situations (to find out whether it's a tty?).

>  avc:  denied  { read } for  pid=693 exe=/usr/bin/perl name=tmp
> dev=dm-3
>  ino=12 scontext=root:system_r:httpd_sys_script_t
>  tcontext=system_u:object_r:tmp_t tclass=lnk_file 
Is this /usr/tmp?  Try running "chcon -h -t usr_t /usr/tmp".  This is a
bug in our policy package because it doesn't presently ensure that it's
relabeled on upgrades.

[Kanwar Ranbir Sandhu]

On Mon, 2005-31-01 at 12:12 -0500, Colin Walters wrote:
>  Have you seen the Fedora Apache/SELinux guide?
>  http://fedora.redhat.com/docs/selinux-apache-fc3/ 
Yes, I read that when I started to migrate SugarCRM from a FC1 box to a
FC3 server, so I'm familiar with selinux.  But, probably not enough to
figure out what's wrong right now.

>  > avc:  denied  { getattr } for  pid=681 exe=/usr/bin/perl
> path=/var/log
>  > dev=dm-5 ino=129025 scontext=root:system_r:httpd_sys_script_t
>  > tcontext=system_u:object_r:var_log_t tclass=dir
>  
>  Hmm.  Given that we allow access to httpd_log_t which is in the default
>  configuration a subdirectory of var_log_t, I'm surprised that this
>  access is not allowed.  Ideally though the app should not need this. 
In RT, you can define a separate log file instead of having everything
dumped to /var/log/messages.  I haven't tried yet, but I'm assuming if I
disabled the separate log file, this error would disappear.

I would rather keep /var/log/rt.log.  It makes reading the log a lot
easier since it will only contain messages pertaining to RT.

>  > avc:  denied  { ioctl } for  pid=693 exe=/usr/bin/perl
>  > path=/var/log/httpd/error_log dev=dm-5 ino=129070
>  > scontext=root:system_r:httpd_sys_script_t
>  > tcontext=system_u:object_r:httpd_log_t tclass=file
>  
>  This one is probably harmless; I think perl does an ioctl even on
>  regular files in many situations (to find out whether it's a tty?). 
I'll have to look into it.

>  > avc:  denied  { read } for  pid=693 exe=/usr/bin/perl name=tmp
> dev=dm-3
>  > ino=12 scontext=root:system_r:httpd_sys_script_t
>  > tcontext=system_u:object_r:tmp_t tclass=lnk_file
>  
>  Is this /usr/tmp?  Try running "chcon -h -t usr_t /usr/tmp".  This is a
>  bug in our policy package because it doesn't presently ensure that it's
>  relabeled on upgrades. 
Actually, it's just /tmp.  FastCGI dumps its temporary files there while
it's running.  The location can be changed, but in the past (on FC1)
when I've tried using /var/log/httpd/fastcgi, I just get a bunch of
errors about FastCGI not having permission to write to that directory (I
believe the only way I managed to fix that was by changing permissions
on /var/log/httpd to 777).

The command you mentioned above won't work in this case, will it?  I'm
assuming that context is meant only for directories under /usr.

Thanks,

Ranbir

-- 
Kanwar Ranbir Sandhu
Linux Consultant
Systems Aligned Inc.
www.systemsaligned.com

[Colin Walters]

On Mon, 2005-01-31 at 13:16 -0500, Kanwar Ranbir Sandhu wrote:

>  In RT, you can define a separate log file instead of having
> everything
>  dumped to /var/log/messages.  I haven't tried yet, but I'm assuming if I
>  disabled the separate log file, this error would disappear.
>
>  I would rather keep /var/log/rt.log.  It makes reading the log a lot
>  easier since it will only contain messages pertaining to RT. 
Right.  Can you try moving the log into /var/log/httpd?  I can't think
of another solution short of installing the policy sources and adding
the permissions.  My guess is that it is actually this permission that
is stopping the program; the others are likely harmless.

>  Actually, it's just /tmp.   
Is your /tmp a symlink elsewhere?  Or do you actually have a symlink
in /tmp named "tmp"?  Are you *sure* it's really /tmp?  Do an 
"ls -di /tmp" to see if its inode number is 12.  Then do 
"ls -di /usr/tmp".

>  FastCGI dumps its temporary files there while
>  it's running.  The location can be changed, but in the past (on FC1)
>  when I've tried using /var/log/httpd/fastcgi, I just get a bunch of
>  errors about FastCGI not having permission to write to that directory (I
>  believe the only way I managed to fix that was by changing permissions
>  on /var/log/httpd to 777). 
Better to use an ACL than mode 777; e.g. 
"setfacl -m 'apache:rwx' /var/log/httpd".

>  The command you mentioned above won't work in this case, will it?
>  I'm
>  assuming that context is meant only for directories under /usr. 
It only changes the type of the /usr/tmp symlink.  My guess is still
that your program has some code (or a library it uses does) that
tries /usr/tmp first, and is getting permission denial on that symlink
because it should be usr_t, not tmp_t.

[Kanwar Ranbir Sandhu]

On Mon, 2005-31-01 at 13:43 -0500, Colin Walters wrote:
>  Right.  Can you try moving the log into /var/log/httpd?  I can't
> think
>  of another solution short of installing the policy sources and adding
>  the permissions.  My guess is that it is actually this permission that
>  is stopping the program; the others are likely harmless. 
Moving it to /var/log/httpd generated this error in error.log for httpd:

Log file /var/log/httpd/rt.log couldn't be written or created.


/var/log/messages had this to say:

avc:  denied  { read } for  pid=1516 exe=/usr/bin/perl name=tmp dev=dm-3
ino=12 scontext=root:system_r:httpd_sys_script_t
tcontext=system_u:object_r:tmp_t tclass=lnk_file

Plus some more denies for { ioctl }.

Here's the contents of /usr/tmp when apache starts:

[root@mothership tmp]# ls -alZ /usr/tmp/
drwxrwxrwt  root     root     system_u:object_r:tmp_t          .
drwxr-xr-x  root     root     system_u:object_r:var_t          ..
srw-------  apache   apache   root:object_r:httpd_tmp_t
38bb41ae9430107f1ab3add79fbea0aa
drwx------  apache   apache   root:object_r:httpd_tmp_t        dynamic


>  > Actually, it's just /tmp.  
>  
>  Is your /tmp a symlink elsewhere?  Or do you actually have a symlink
>  in /tmp named "tmp"?  Are you *sure* it's really /tmp?  Do an 
>  "ls -di /tmp" to see if its inode number is 12.  Then do 
>  "ls -di /usr/tmp". 
Well, it's not 12.

[root@mothership ~]# ls -di /tmp
2 /tmp


But:

[root@mothership tmp]# ls -di /usr/tmp
12 /usr/tmp


So...I changed the parameter for FastCgiIpDir to /usr/tmp, but there
were still more denials (a new one):

avc:  denied  { getattr } for  pid=2014 exe=/usr/bin/perl path=/var/log
dev=dm-5 ino=129025 scontext=root:system_r:httpd_sys_script_t
tcontext=system_u:object_r:var_log_t tclass=dir


A ls -alZ shows that /tmp is a normal directory:

drwxrwxrwt  root     root     system_u:object_r:tmp_t          tmp


The same command within /tmp:

[root@mothership tmp]# ls -alZ
drwxrwxrwt  root     root     system_u:object_r:tmp_t          .
drwxr-xr-x  root     root     system_u:object_r:root_t         ..
-rw-r--r--  root     root     root:object_r:tmp_t
49822b18a8485fff12354f4fbd601494
-rw-r--r--  root     root     root:object_r:tmp_t              Apache-
Session-49822b18a8485fff12354f4fbd601494.lock
drwxr-xr-x  root     root     root:object_r:tmp_t              .cpan
drwx------  apache   apache   root:object_r:httpd_tmp_t        dynamic
drwxr-xr-x  root     root     root:object_r:tmp_t              fastcgi
drwxrwxrwx  root     root     root:object_r:tmp_t              FileCache
drwxrwxrwt  root     root     user_u:object_r:tmp_t            .font-
unix
-rw-r--r--  root     root     root:object_r:tmp_t              html-
scrubber.test.html
-rw-r--r--  root     root     root:object_r:tmp_t              html-
scrubber.test.html.html
drwxrwxrwt  root     root     user_u:object_r:tmp_t            .ICE-unix
drwx------  root     root                                      lost
+found


You can see the files and directories created by FastCGI when Apache
fires up (when I had the FastCgiIpDir set to /tmp).

>  Better to use an ACL than mode 777; e.g. 
>  "setfacl -m 'apache:rwx' /var/log/httpd". 
I got a "Operation not supported" error:

setfacl: /var/log/httpd: Operation not supported


>  It only changes the type of the /usr/tmp symlink.  My guess is still
>  that your program has some code (or a library it uses does) that
>  tries /usr/tmp first, and is getting permission denial on that symlink
>  because it should be usr_t, not tmp_t. 
A good try, but it didn't work. :(

I actually tried turning off the separate log entirely, but I still
received errors:

avc:  denied  { ioctl } for  pid=2305 exe=/usr/bin/perl
path=/var/log/httpd/error_log dev=dm-5 ino=129070
scontext=root:system_r:httpd_sys_script_t
tcontext=system_u:object_r:httpd_log_t tclass=file

Me = stumped.

Thanks for the help.

Regards,

Ranbir
-- 
Kanwar Ranbir Sandhu
Linux Consultant
Systems Aligned Inc.
www.systemsaligned.com

[Colin Walters]

On Mon, 2005-01-31 at 19:34 -0500, Kanwar Ranbir Sandhu wrote:
>  On Mon, 2005-31-01 at 13:43 -0500, Colin Walters wrote:
>  > Right.  Can you try moving the log into /var/log/httpd?  I can't think
>  > of another solution short of installing the policy sources and adding
>  > the permissions.  My guess is that it is actually this permission that
>  > is stopping the program; the others are likely harmless.
>  
>  Moving it to /var/log/httpd generated this error in error.log for httpd:
>  
>  Log file /var/log/httpd/rt.log couldn't be written or created. 
Is the type on rt.log still httpd_log_t?  Use ls -Z to inspect.

>  [root@mothership tmp]# ls -di /usr/tmp
>  12 /usr/tmp 
Yeah, that's what I thought.  If you look at the denial message, the
inode number was 12.  If your /usr isn't on a separate filesystem, then
you know the denial was on the /usr/tmp symlink.

I'm baffled you're still getting the denial though.  Can you confirm
with "ls -dZ /usr/tmp" that the type is usr_t?

>  avc:  denied  { getattr } for  pid=2014 exe=/usr/bin/perl
> path=/var/log
>  dev=dm-5 ino=129025 scontext=root:system_r:httpd_sys_script_t
>  tcontext=system_u:object_r:var_log_t tclass=dir 
If after everything else doesn't work, here's what you can do:

yum install selinux-policy-targeted-sources
cd /etc/selinux/targeted/src/policy
echo 'allow httpd_sys_script_t var_log_t:dir { getattr search }' >
domains/misc/local.te
make reload

There's work going on in SELinux upstream to make this easier.

>  I got a "Operation not supported" error:
>  
>  setfacl: /var/log/httpd: Operation not supported 
Try:

mount -oremount,acl /

This should be the default IMO; also note you need to do it for each
filesystem you want ACLs on.

>  I actually tried turning off the separate log entirely, but I still
>  received errors:
>  
>  avc:  denied  { ioctl } for  pid=2305 exe=/usr/bin/perl
>  path=/var/log/httpd/error_log dev=dm-5 ino=129070
>  scontext=root:system_r:httpd_sys_script_t
>  tcontext=system_u:object_r:httpd_log_t tclass=file 
I'd be fairly surprised if this is really the problem preventing the
program from working.  Was this the only denial you got after turning
off the separate log?

Anyways, this shouldn't be harmful to turn on (following the previous
steps):
echo 'allow httpd_sys_script_t httpd_log_t:file { ioctl };' >>
domains/misc/local.te
make reload

>  Me = stumped. 
Hope the above helps.  Sometimes debugging this stuff can be a huge pain
if you have to dig into some obscure Perl library or the like, other
times it's a very simple fix.  This unfortunately looks to be one of the
former cases :/

[Kanwar Ranbir Sandhu]

On Mon, 2005-31-01 at 20:07 -0500, Colin Walters wrote:
>  > Moving it to /var/log/httpd generated this error in error.log
> for httpd:
>  > 
>  > Log file /var/log/httpd/rt.log couldn't be written or created.
>  
>  Is the type on rt.log still httpd_log_t?  Use ls -Z to inspect. 
Yes it is...after I created the file by hand! :)  In any case, it didn't
help.

>  > [root@mothership tmp]# ls -di /usr/tmp
>  > 12 /usr/tmp
>  
>  Yeah, that's what I thought.  If you look at the denial message, the
>  inode number was 12.  If your /usr isn't on a separate filesystem, then
>  you know the denial was on the /usr/tmp symlink.
>  
>  I'm baffled you're still getting the denial though.  Can you confirm
>  with "ls -dZ /usr/tmp" that the type is usr_t? 
Yes, the type is usr_t.  BTW, I have /usr mounted on a separate
partition (actually, the whole server is setup up with LVM).

>  > avc:  denied  { getattr } for  pid=2014 exe=/usr/bin/perl
> path=/var/log
>  > dev=dm-5 ino=129025 scontext=root:system_r:httpd_sys_script_t
>  > tcontext=system_u:object_r:var_log_t tclass=dir
>  
>  If after everything else doesn't work, here's what you can do: 
I wanted to keep hacking away, but I couldn't take it anymore.  I setup
RT with modperl2 instead, and viola, it worked.  RT 3.2.2 is running.

There are still denials, though I haven't noticed any problems in the
app itself (here are two):

 avc:  denied  { ioctl } for  pid=4439 exe=/usr/sbin/httpd
path=/var/www/rt/bin/webmux.pl dev=dm-5 ino=28748
scontext=root:system_r:httpd_t
tcontext=root:object_r:httpd_sys_script_exec_t tclass=file

avc:  denied  { create } for  pid=4439 exe=/usr/sbin/httpd name=fastcgi
scontext=root:system_r:httpd_t tcontext=root:object_r:httpd_log_t
tclass=dir

Thank you very much for your help.  Not having solved the problem with
FastCGI is obviously bad since getting selinux to work would have been
the better answer.

Regards,

Ranbir
-- 
Kanwar Ranbir Sandhu
Linux Consultant
Systems Aligned Inc.
www.systemsaligned.com

[Kanwar Ranbir Sandhu]

Well, the web interface is working just fine, but there's a problem with
the auto-replies etc. that RT emails when it receives a new email.

I sent a test email to RT, and the ticket was created okay.  However,
selinux kicked in and denied RT to send an auto-reply.  Here are the
errors:

avc:  denied  { search } for  pid=2851 exe=/usr/bin/perl name=postfix
dev=dm-5 ino=34833 scontext=user_u:system_r:httpd_sys_script_t
tcontext=system_u:object_r:var_spool_t tclass=dir

avc:  denied  { search } for  pid=2851 exe=/usr/bin/perl name=postfix
dev=dm-5 ino=34833 scontext=user_u:system_r:httpd_sys_script_t
tcontext=system_u:object_r:var_spool_t tclass=dir

avc:  denied  { setrlimit } for  pid=2856 exe=/usr/sbin/sendmail.postfix
scontext=user_u:system_r:httpd_t tcontext=user_u:system_r:httpd_t
tclass=process

RT: <rt-3.2.2-2321-11280-39.0.453193598451378(a)systemsaligned.com&gt;Could
not send mail. (/var/www/rt/lib/RT/Action/SendEmail.pm:276)


So, it looks to me like selinux won't let perl use postfix.  

I get the feeling that not many people are using RT with selinux turned
on in FC3 (there just aren't any posts about this to the RT mailing
list).

Thanks in advance.

Regards,

Ranbir
-- 
Kanwar Ranbir Sandhu
Linux Consultant
Systems Aligned Inc.
www.systemsaligned.com

[Kanwar Ranbir Sandhu]

On Tue, 2005-01-02 at 10:22 -0500, Kanwar Ranbir Sandhu wrote:
>  avc:  denied  { search } for  pid=2851 exe=/usr/bin/perl
> name=postfix
>  dev=dm-5 ino=34833 scontext=user_u:system_r:httpd_sys_script_t
>  tcontext=system_u:object_r:var_spool_t tclass=dir
>  
>  avc:  denied  { search } for  pid=2851 exe=/usr/bin/perl name=postfix
>  dev=dm-5 ino=34833 scontext=user_u:system_r:httpd_sys_script_t
>  tcontext=system_u:object_r:var_spool_t tclass=dir
>  
>  avc:  denied  { setrlimit } for  pid=2856 exe=/usr/sbin/sendmail.postfix
>  scontext=user_u:system_r:httpd_t tcontext=user_u:system_r:httpd_t
>  tclass=process 
I've learned a little more about selinux, and so ran audit2allow on the
denials above to generate the following two policies:

allow httpd_sys_script_t var_spool_t:dir search;
allow httpd_t self:process setrlimit;

I know I can use dontaudit to turn off auditing for these policies
(instead of allowing), but I don't know if that's a good idea, or even
the right approach.

Thanks,

Ranbir
-- 
Kanwar Ranbir Sandhu
Linux Consultant
Systems Aligned Inc.
www.systemsaligned.com

[Colin Walters]

On Tue, 2005-02-01 at 11:52 -0500, Kanwar Ranbir Sandhu wrote:
>  On Tue, 2005-01-02 at 10:22 -0500, Kanwar Ranbir Sandhu wrote:
>  > avc:  denied  { search } for  pid=2851 exe=/usr/bin/perl name=postfix
>  > dev=dm-5 ino=34833 scontext=user_u:system_r:httpd_sys_script_t
>  > tcontext=system_u:object_r:var_spool_t tclass=dir
>  > 
>  > avc:  denied  { search } for  pid=2851 exe=/usr/bin/perl name=postfix
>  > dev=dm-5 ino=34833 scontext=user_u:system_r:httpd_sys_script_t
>  > tcontext=system_u:object_r:var_spool_t tclass=dir
>  > 
>  > avc:  denied  { setrlimit } for  pid=2856 exe=/usr/sbin/sendmail.postfix
>  > scontext=user_u:system_r:httpd_t tcontext=user_u:system_r:httpd_t
>  > tclass=process
>  
>  I've learned a little more about selinux, and so ran audit2allow on the
>  denials above to generate the following two policies:
>  
>  allow httpd_sys_script_t var_spool_t:dir search;
>  allow httpd_t self:process setrlimit; 
Does adding those two permissions actually fix the problem?

[Colin Walters]

On Tue, 2005-02-01 at 10:22 -0500, Kanwar Ranbir Sandhu wrote:

>  avc:  denied  { search } for  pid=2851 exe=/usr/bin/perl
> name=postfix
>  dev=dm-5 ino=34833 scontext=user_u:system_r:httpd_sys_script_t
>  tcontext=system_u:object_r:var_spool_t tclass=dir
>  
>  avc:  denied  { search } for  pid=2851 exe=/usr/bin/perl name=postfix
>  dev=dm-5 ino=34833 scontext=user_u:system_r:httpd_sys_script_t
>  tcontext=system_u:object_r:var_spool_t tclass=dir 
Hmmm.  Surely the SendEmail.pm perl module doesn't scribble on the
postfix queue directly; I don't think that's supported.

>  avc:  denied  { setrlimit } for  pid=2856
> exe=/usr/sbin/sendmail.postfix
>  scontext=user_u:system_r:httpd_t tcontext=user_u:system_r:httpd_t
>  tclass=process 
It looks like there was no transition to system_mail_t
because /usr/sbin/sendmail.postfix isn't labeled as sendmail_exec_t in
the targeted policy.

Try:

chcon -h -t sendmail_exec_t /usr/sbin/sendmail.postfix

[Kanwar Ranbir Sandhu]

On Tue, 2005-01-02 at 18:58 -0500, Colin Walters wrote:
>  Hmmm.  Surely the SendEmail.pm perl module doesn't scribble on
> the
>  postfix queue directly; I don't think that's supported. 
I don't know enough about the innards of RT to answer your question.
However, I've sent an email to the RT list about this.  Hopefully somone
will chime in;  I'll let you know.

>  Try:
>  
>  chcon -h -t sendmail_exec_t /usr/sbin/sendmail.postfix 
That got rid of the { setrlimit } denial, and produced a new one:

avc:  denied  { execute } for  pid=5736 exe=/usr/sbin/sendmail.postfix
name=postdrop dev=dm-3 ino=276825 scontext=root:system_r:system_mail_t
tcontext=system_u:object_r:sbin_t tclass=file


Now, I don't want to confuse the issue, but in RT you define the mail
command as 'sendmail' or 'sendmailpipe'.  If using sendmail, then the
arguements are '-oi'.  If it's sendmailpipe, the arguements are '-oi -
t', and the location of the sendmail binary must be specified
(/usr/sbin/sendmail).

The above error was generated with the mail command in RT to sendmail.
When I set the mail command to sendmailpipe, I got this denial:

avc:  denied  { read } for  pid=5977 exe=/usr/sbin/httpd name=sendmail
dev=dm-3 ino=277369 scontext=root:system_r:httpd_t
tcontext=user_u:object_r:sbin_t tclass=lnk_file


I then changed the location of the sendmail binary parameter in RT
to /usr/sbin/sendmail.postfix (but kept the mail command as
sendmailpipe):

avc:  denied  { execute } for  pid=6019 exe=/usr/sbin/sendmail.postfix
name=postdrop dev=dm-3 ino=276825 scontext=root:system_r:system_mail_t
tcontext=system_u:object_r:sbin_t tclass=file

That's the same denial as the very first one listed above.

I just wanted to point that out.  In the past, I have configured RT
with:

mail command: sendmail
arguements: -oi
path: /usr/sbin/sendmail

So, that's what I'll be sticking with, unless something else comes up.

It seems the solution is a little closer...

Regards,

Ranbir
-- 
Kanwar Ranbir Sandhu
Linux Consultant
Systems Aligned Inc.
www.systemsaligned.com

[Daniel J Walsh]

Kanwar Ranbir Sandhu wrote:

> On Tue, 2005-01-02 at 18:58 -0500, Colin Walters wrote:
>   
>
> >Hmmm.  Surely the SendEmail.pm perl module doesn't scribble on the
> >postfix queue directly; I don't think that's supported.
> >    
> >
>
> I don't know enough about the innards of RT to answer your question.
> However, I've sent an email to the RT list about this.  Hopefully somone
> will chime in;  I'll let you know.
>
>   
>
> >Try:
> >
> >chcon -h -t sendmail_exec_t /usr/sbin/sendmail.postfix
> >    
> >
>
> That got rid of the { setrlimit } denial, and produced a new one:
>
> avc:  denied  { execute } for  pid=5736 exe=/usr/sbin/sendmail.postfix
> name=postdrop dev=dm-3 ino=276825 scontext=root:system_r:system_mail_t
> tcontext=system_u:object_r:sbin_t tclass=file
>
>
> Now, I don't want to confuse the issue, but in RT you define the mail
> command as 'sendmail' or 'sendmailpipe'.  If using sendmail, then the
> arguements are '-oi'.  If it's sendmailpipe, the arguements are '-oi -
> t', and the location of the sendmail binary must be specified
> (/usr/sbin/sendmail).
>
> The above error was generated with the mail command in RT to sendmail.
> When I set the mail command to sendmailpipe, I got this denial:
>
> avc:  denied  { read } for  pid=5977 exe=/usr/sbin/httpd name=sendmail
> dev=dm-3 ino=277369 scontext=root:system_r:httpd_t
> tcontext=user_u:object_r:sbin_t tclass=lnk_file
>
>
> I then changed the location of the sendmail binary parameter in RT
> to /usr/sbin/sendmail.postfix (but kept the mail command as
> sendmailpipe):
>
> avc:  denied  { execute } for  pid=6019 exe=/usr/sbin/sendmail.postfix
> name=postdrop dev=dm-3 ino=276825 scontext=root:system_r:system_mail_t
> tcontext=system_u:object_r:sbin_t tclass=file
>
> That's the same denial as the very first one listed above.
>
> I just wanted to point that out.  In the past, I have configured RT
> with:
>
> mail command: sendmail
> arguements: -oi
> path: /usr/sbin/sendmail
>
> So, that's what I'll be sticking with, unless something else comes up.
>
> It seems the solution is a little closer...
>
> Regards,
>
> Ranbir
>   
>  
Rather than going down a rathole, here could
you
setenforce 0
Run both test and send the avc messages.

[Kanwar Ranbir Sandhu]

On Wed, 2005-02-02 at 10:10 -0500, Daniel J Walsh wrote: 
>  Rather than going down a rathole, here could
>  you
>  setenforce 0
>  Run both test and send the avc messages. 
Okay, no problem.  I'll describe the mail setups, proceeded by the
selinux messages for each.

Mail config in RT:
------------------
mail command: sendmailpipe
arguements: -oi -t         #(-t required, as stated in RT docs)
path: /usr/sbin/sendmail

avc messages:
-------------
avc:  denied  { read } for  pid=6130 exe=/usr/sbin/httpd name=sendmail
dev=dm-3 ino=277369 scontext=root:system_r:httpd_t
tcontext=user_u:object_r:sbin_t tclass=lnk_file


Mail config in RT:
------------------
mail command: sendmail
arguements: -oi
path: /usr/sbin/sendmail #(not read when mail command set to sendmail)

avc messages:
-------------
avc:  denied  { search } for  pid=6082 exe=/usr/bin/perl name=postfix
dev=dm-5 ino=34833 scontext=user_u:system_r:httpd_sys_script_t
tcontext=system_u:object_r:var_spool_t tclass=dir

avc:  denied  { getattr } for  pid=6086 exe=/usr/sbin/sendmail.postfix
path=socket:[14139] dev=sockfs ino=14139
scontext=root:system_r:system_mail_t tcontext=root:system_r:httpd_t
tclass=unix_stream_socket

avc:  denied  { execute } for  pid=6087 exe=/usr/sbin/sendmail.postfix
name=postdrop dev=dm-3 ino=276825 scontext=root:system_r:system_mail_t
tcontext=system_u:object_r:sbin_t tclass=file

avc:  denied  { execute_no_trans } for  pid=6087
exe=/usr/sbin/sendmail.postfix path=/usr/sbin/postdrop dev=dm-3
ino=276825 scontext=root:system_r:system_mail_t
tcontext=system_u:object_r:sbin_t tclass=file

avc:  denied  { read } for  pid=6087 exe=/usr/sbin/sendmail.postfix
path=/usr/sbin/postdrop dev=dm-3 ino=276825
scontext=root:system_r:system_mail_t tcontext=system_u:object_r:sbin_t
tclass=file

avc:  denied  { write } for  pid=6087 exe=/usr/sbin/postdrop
name=maildrop dev=dm-5 ino=34842 scontext=root:system_r:system_mail_t
tcontext=system_u:object_r:var_spool_t tclass=dir

avc:  denied  { add_name } for  pid=6087 exe=/usr/sbin/postdrop
name=1290.6087 scontext=root:system_r:system_mail_t
tcontext=system_u:object_r:var_spool_t tclass=dir

avc:  denied  { create } for  pid=6087 exe=/usr/sbin/postdrop
name=1290.6087 scontext=root:system_r:system_mail_t
tcontext=root:object_r:var_spool_t tclass=file

avc:  denied  { getattr } for  pid=6087 exe=/usr/sbin/postdrop
path=/var/spool/postfix/maildrop/1290.6087 dev=dm-5 ino=34911
scontext=root:system_r:system_mail_t tcontext=root:object_r:var_spool_t
tclass=file

avc:  denied  { remove_name } for  pid=6087 exe=/usr/sbin/postdrop
name=1290.6087 dev=dm-5 ino=34911 scontext=root:system_r:system_mail_t
tcontext=system_u:object_r:var_spool_t tclass=dir

avc:  denied  { rename } for  pid=6087 exe=/usr/sbin/postdrop
name=1290.6087 dev=dm-5 ino=34911 scontext=root:system_r:system_mail_t
tcontext=root:object_r:var_spool_t tclass=file

avc:  denied  { write } for  pid=6087 exe=/usr/sbin/postdrop
path=/var/spool/postfix/maildrop/1ACA7885F dev=dm-5 ino=34911
scontext=root:system_r:system_mail_t tcontext=root:object_r:var_spool_t
tclass=file

avc:  denied  { setattr } for  pid=6087 exe=/usr/sbin/postdrop
name=1ACA7885F dev=dm-5 ino=34911 scontext=root:system_r:system_mail_t
tcontext=root:object_r:var_spool_t tclass=file

avc:  denied  { getattr } for  pid=6087 exe=/usr/sbin/postdrop
path=/var/spool/postfix/public/pickup dev=dm-5 ino=34827
scontext=root:system_r:system_mail_t
tcontext=user_u:object_r:var_spool_t tclass=fifo_file

avc:  denied  { write } for  pid=6087 exe=/usr/sbin/postdrop name=pickup
dev=dm-5 ino=34827 scontext=root:system_r:system_mail_t
tcontext=user_u:object_r:var_spool_t tclass=fifo_file

Wow.  Big difference in denials.

Regards,

Ranbir
-- 
Kanwar Ranbir Sandhu
Linux Consultant
Systems Aligned Inc.
www.systemsaligned.com

[Daniel J Walsh]

Kanwar Ranbir Sandhu wrote:

> On Wed, 2005-02-02 at 10:10 -0500, Daniel J Walsh wrote: 
>   
>
> >Rather than going down a rathole, here could
> >you
> >setenforce 0
> >Run both test and send the avc messages.
> >    
> >
>
> Okay, no problem.  I'll describe the mail setups, proceeded by the
> selinux messages for each.
>
> Mail config in RT:
> ------------------
> mail command: sendmailpipe
> arguements: -oi -t         #(-t required, as stated in RT docs)
> path: /usr/sbin/sendmail
>
> avc messages:
> -------------
> avc:  denied  { read } for  pid=6130 exe=/usr/sbin/httpd name=sendmail
> dev=dm-3 ino=277369 scontext=root:system_r:httpd_t
> tcontext=user_u:object_r:sbin_t tclass=lnk_file
>
>
> Mail config in RT:
> ------------------
> mail command: sendmail
> arguements: -oi
> path: /usr/sbin/sendmail #(not read when mail command set to sendmail)
>
> avc messages:
> -------------
> avc:  denied  { search } for  pid=6082 exe=/usr/bin/perl name=postfix
> dev=dm-5 ino=34833 scontext=user_u:system_r:httpd_sys_script_t
> tcontext=system_u:object_r:var_spool_t tclass=dir
>
> avc:  denied  { getattr } for  pid=6086 exe=/usr/sbin/sendmail.postfix
> path=socket:[14139] dev=sockfs ino=14139
> scontext=root:system_r:system_mail_t tcontext=root:system_r:httpd_t
> tclass=unix_stream_socket
>
> avc:  denied  { execute } for  pid=6087 exe=/usr/sbin/sendmail.postfix
> name=postdrop dev=dm-3 ino=276825 scontext=root:system_r:system_mail_t
> tcontext=system_u:object_r:sbin_t tclass=file
>
> avc:  denied  { execute_no_trans } for  pid=6087
> exe=/usr/sbin/sendmail.postfix path=/usr/sbin/postdrop dev=dm-3
> ino=276825 scontext=root:system_r:system_mail_t
> tcontext=system_u:object_r:sbin_t tclass=file
>
> avc:  denied  { read } for  pid=6087 exe=/usr/sbin/sendmail.postfix
> path=/usr/sbin/postdrop dev=dm-3 ino=276825
> scontext=root:system_r:system_mail_t tcontext=system_u:object_r:sbin_t
> tclass=file
>
> avc:  denied  { write } for  pid=6087 exe=/usr/sbin/postdrop
> name=maildrop dev=dm-5 ino=34842 scontext=root:system_r:system_mail_t
> tcontext=system_u:object_r:var_spool_t tclass=dir
>
> avc:  denied  { add_name } for  pid=6087 exe=/usr/sbin/postdrop
> name=1290.6087 scontext=root:system_r:system_mail_t
> tcontext=system_u:object_r:var_spool_t tclass=dir
>
> avc:  denied  { create } for  pid=6087 exe=/usr/sbin/postdrop
> name=1290.6087 scontext=root:system_r:system_mail_t
> tcontext=root:object_r:var_spool_t tclass=file
>
> avc:  denied  { getattr } for  pid=6087 exe=/usr/sbin/postdrop
> path=/var/spool/postfix/maildrop/1290.6087 dev=dm-5 ino=34911
> scontext=root:system_r:system_mail_t tcontext=root:object_r:var_spool_t
> tclass=file
>
> avc:  denied  { remove_name } for  pid=6087 exe=/usr/sbin/postdrop
> name=1290.6087 dev=dm-5 ino=34911 scontext=root:system_r:system_mail_t
> tcontext=system_u:object_r:var_spool_t tclass=dir
>
> avc:  denied  { rename } for  pid=6087 exe=/usr/sbin/postdrop
> name=1290.6087 dev=dm-5 ino=34911 scontext=root:system_r:system_mail_t
> tcontext=root:object_r:var_spool_t tclass=file
>
> avc:  denied  { write } for  pid=6087 exe=/usr/sbin/postdrop
> path=/var/spool/postfix/maildrop/1ACA7885F dev=dm-5 ino=34911
> scontext=root:system_r:system_mail_t tcontext=root:object_r:var_spool_t
> tclass=file
>
> avc:  denied  { setattr } for  pid=6087 exe=/usr/sbin/postdrop
> name=1ACA7885F dev=dm-5 ino=34911 scontext=root:system_r:system_mail_t
> tcontext=root:object_r:var_spool_t tclass=file
>
> avc:  denied  { getattr } for  pid=6087 exe=/usr/sbin/postdrop
> path=/var/spool/postfix/public/pickup dev=dm-5 ino=34827
> scontext=root:system_r:system_mail_t
> tcontext=user_u:object_r:var_spool_t tclass=fifo_file
>
> avc:  denied  { write } for  pid=6087 exe=/usr/sbin/postdrop name=pickup
> dev=dm-5 ino=34827 scontext=root:system_r:system_mail_t
> tcontext=user_u:object_r:var_spool_t tclass=fifo_file
>
> Wow.  Big difference in denials.
>
> Regards,
>
> Ranbir
>   
>  
Ok one more change. 

could you d a

chcon -R -t mail_spool_t /var/spool/postfix

And try it again?

Dan

[Kanwar Ranbir Sandhu]

On Wed, 2005-02-02 at 10:56 -0500, Daniel J Walsh wrote:
>  could you d a
>  
>  chcon -R -t mail_spool_t /var/spool/postfix 

Mail config in RT:
------------------
mail command: sendmail
arguments: -oi
path: /usr/sbin/sendmail

avc messages:
-------------
None! RT received the email and sent out an auto-reply without any
selinux denials!  

However, the other email config produced many more selinux denials than
before (last time there was only one message).  I included the messages
below anyway.


Mail config in RT:
------------------
mail command: sendmailpipe
arguments: -oi -t         #(-t required, as stated in RT docs)
path: /usr/sbin/sendmail

avc messages:
-------------
avc:  denied  { search } for  pid=6171 exe=/usr/bin/perl name=postfix
dev=dm-5 ino=34833 scontext=user_u:system_r:httpd_sys_script_t
tcontext=system_u:object_r:mail_spool_t tclass=dir

avc:  denied  { read } for  pid=6173 exe=/usr/sbin/httpd name=sendmail
dev=dm-3 ino=277369 scontext=root:system_r:httpd_t
tcontext=user_u:object_r:sbin_t tclass=lnk_file

avc:  denied  { getattr } for  pid=6173 exe=/usr/sbin/sendmail.postfix
path=socket:[14495] dev=sockfs ino=14495
scontext=root:system_r:system_mail_t tcontext=root:system_r:httpd_t
tclass=unix_stream_socket

avc:  denied  { search } for  pid=6173 exe=/usr/sbin/sendmail.postfix
name=postfix dev=dm-5 ino=34833 scontext=root:system_r:system_mail_t
tcontext=system_u:object_r:mail_spool_t tclass=dir

avc:  denied  { execute } for  pid=6174 exe=/usr/sbin/sendmail.postfix
name=postdrop dev=dm-3 ino=276825 scontext=root:system_r:system_mail_t
tcontext=system_u:object_r:sbin_t tclass=file

avc:  denied  { execute_no_trans } for  pid=6174
exe=/usr/sbin/sendmail.postfix path=/usr/sbin/postdrop dev=dm-3
ino=276825 scontext=root:system_r:system_mail_t
tcontext=system_u:object_r:sbin_t tclass=file

avc:  denied  { read } for  pid=6174 exe=/usr/sbin/sendmail.postfix
path=/usr/sbin/postdrop dev=dm-3 ino=276825
scontext=root:system_r:system_mail_t tcontext=system_u:object_r:sbin_t
tclass=file

avc:  denied  { write } for  pid=6174 exe=/usr/sbin/postdrop
name=maildrop dev=dm-5 ino=34842 scontext=root:system_r:system_mail_t
tcontext=system_u:object_r:mail_spool_t tclass=dir

avc:  denied  { add_name } for  pid=6174 exe=/usr/sbin/postdrop
name=530173.6174 scontext=root:system_r:system_mail_t
tcontext=system_u:object_r:mail_spool_t tclass=dir

avc:  denied  { create } for  pid=6174 exe=/usr/sbin/postdrop
name=530173.6174 scontext=root:system_r:system_mail_t
tcontext=root:object_r:mail_spool_t tclass=file

avc:  denied  { getattr } for  pid=6174 exe=/usr/sbin/postdrop
path=/var/spool/postfix/maildrop/530173.6174 dev=dm-5 ino=34911
scontext=root:system_r:system_mail_t tcontext=root:object_r:mail_spool_t
tclass=file

avc:  denied  { remove_name } for  pid=6174 exe=/usr/sbin/postdrop
name=530173.6174 dev=dm-5 ino=34911 scontext=root:system_r:system_mail_t
tcontext=system_u:object_r:mail_spool_t tclass=dir

avc:  denied  { rename } for  pid=6174 exe=/usr/sbin/postdrop
name=530173.6174 dev=dm-5 ino=34911 scontext=root:system_r:system_mail_t
tcontext=root:object_r:mail_spool_t tclass=file

avc:  denied  { write } for  pid=6174 exe=/usr/sbin/postdrop
path=/var/spool/postfix/maildrop/9BD83885F dev=dm-5 ino=34911
scontext=root:system_r:system_mail_t tcontext=root:object_r:mail_spool_t
tclass=file

avc:  denied  { setattr } for  pid=6174 exe=/usr/sbin/postdrop
name=9BD83885F dev=dm-5 ino=34911 scontext=root:system_r:system_mail_t
tcontext=root:object_r:mail_spool_t tclass=file

avc:  denied  { getattr } for  pid=6174 exe=/usr/sbin/postdrop
path=/var/spool/postfix/public/pickup dev=dm-5 ino=34827
scontext=root:system_r:system_mail_t
tcontext=user_u:object_r:mail_spool_t tclass=fifo_file

avc:  denied  { write } for  pid=6174 exe=/usr/sbin/postdrop name=pickup
dev=dm-5 ino=34827 scontext=root:system_r:system_mail_t
tcontext=user_u:object_r:mail_spool_t tclass=fifo_file


Regards,

Ranbir
-- 
Kanwar Ranbir Sandhu
Linux Consultant
Systems Aligned Inc.
www.systemsaligned.com

[Kanwar Ranbir Sandhu]

On Tue, 2005-01-02 at 18:58 -0500, Colin Walters wrote:
>  Hmmm.  Surely the SendEmail.pm perl module doesn't scribble on
> the
>  postfix queue directly; I don't think that's supported. 
Jesse Vincent, one of the developers (actually, he started the whole
thing), replied.  Here's his message:

---start---
No. RT generally opens /usr/sbin/sendmail (or whateveryou've configured)
and pipes the message to it, just like you'd do with

cat "/tmp/msgfile" |/usr/sbin/sendmail -oi -t
---end---

Makes sense, especially considering the options passed to sendmail.  I
should have realized that.

Regards,

Ranbir
-- 
Kanwar Ranbir Sandhu
Linux Consultant
Systems Aligned Inc.
www.systemsaligned.com

[Daniel J Walsh]

Kanwar Ranbir Sandhu wrote:

> On Tue, 2005-01-02 at 18:58 -0500, Colin Walters wrote:
>   
>
> >Hmmm.  Surely the SendEmail.pm perl module doesn't scribble on the
> >postfix queue directly; I don't think that's supported.
> >    
> >
>
> Jesse Vincent, one of the developers (actually, he started the whole
> thing), replied.  Here's his message:
>
> ---start---
> No. RT generally opens /usr/sbin/sendmail (or whateveryou've configured)
> and pipes the message to it, just like you'd do with
>
> cat "/tmp/msgfile" |/usr/sbin/sendmail -oi -t
> ---end---
>
> Makes sense, especially considering the options passed to sendmail.  I
> should have realized that.
>
> Regards,
>
> Ranbir
>   
>  
I think we are going to have to work on this here and setup a postfix 
mail system to
see if we can get it to work.  For the time being you might want to 
change the
turn httpd transitioning off.

setsebool -P httpd_disable_trans 1

[Kanwar Ranbir Sandhu]

On Wed, 2005-02-02 at 12:42 -0500, Daniel J Walsh wrote:
>  I think we are going to have to work on this here and setup a postfix
>
>  mail system to
>  see if we can get it to work.  For the time being you might want to 
>  change the
>  turn httpd transitioning off.
>  
>  setsebool -P httpd_disable_trans 1 
Thanks, but now that RT is working with the config I mentioned in my
other message, I'm not so concerned (you read my other message,
right?).  

I am a little worried that a future selinux update will wipe out what
you and Colin helped me with.  Gotta make some notes...

Again, thanks for your help.  It's good to see RT running with selinux
in place.  I'll have to report this to the RT list.

Regards,

Ranbir
-- 
Kanwar Ranbir Sandhu
Linux Consultant
Systems Aligned Inc.
www.systemsaligned.com

[Kanwar Ranbir Sandhu]

I spoke too soon.  It's still not working.  For some reason I sent a few
emails, and there were no denials.  I waited a few minutes, and then
tried again, and lo and behold, the denials were back.

So, my other message was partially incorrect (the part about there not
being any denials when setting the mail command to "sendmail").  After
running "chcon -R -t mail_spool_t /var/spool/postfix", these were the
denials eventually reported (there a few new ones):

avc:  denied  { search } for  pid=6845 exe=/usr/bin/perl name=postfix
dev=dm-5 ino=34833 scontext=user_u:system_r:httpd_sys_script_t
tcontext=system_u:object_r:mail_spool_t tclass=dir

avc:  denied  { getattr } for  pid=6847 exe=/usr/sbin/sendmail.postfix
path=socket:[17672] dev=sockfs ino=17672
scontext=root:system_r:system_mail_t tcontext=root:system_r:httpd_t
tclass=unix_stream_socket

avc:  denied  { search } for  pid=6847 exe=/usr/sbin/sendmail.postfix
name=postfix dev=dm-5 ino=34833 scontext=root:system_r:system_mail_t
tcontext=system_u:object_r:mail_spool_t tclass=dir

avc:  denied  { execute } for  pid=6848 exe=/usr/sbin/sendmail.postfix
name=postdrop dev=dm-3 ino=276825 scontext=root:system_r:system_mail_t
tcontext=system_u:object_r:sbin_t tclass=file

avc:  denied  { execute_no_trans } for  pid=6848
exe=/usr/sbin/sendmail.postfix path=/usr/sbin/postdrop dev=dm-3
ino=276825 scontext=root:system_r:system_mail_t
tcontext=system_u:object_r:sbin_t tclass=file

avc:  denied  { read } for  pid=6848 exe=/usr/sbin/sendmail.postfix
path=/usr/sbin/postdrop dev=dm-3 ino=276825
scontext=root:system_r:system_mail_t tcontext=system_u:object_r:sbin_t
tclass=file

avc:  denied  { write } for  pid=6848 exe=/usr/sbin/postdrop
name=maildrop dev=dm-5 ino=34842 scontext=root:system_r:system_mail_t
tcontext=system_u:object_r:mail_spool_t tclass=dir

avc:  denied  { add_name } for  pid=6848 exe=/usr/sbin/postdrop
name=964455.6848 scontext=root:system_r:system_mail_t
tcontext=system_u:object_r:mail_spool_t tclass=dir

avc:  denied  { create } for  pid=6848 exe=/usr/sbin/postdrop
name=964455.6848 scontext=root:system_r:system_mail_t
tcontext=root:object_r:mail_spool_t tclass=file

avc:  denied  { getattr } for  pid=6848 exe=/usr/sbin/postdrop
path=/var/spool/postfix/maildrop/964455.6848 dev=dm-5 ino=34911
scontext=root:system_r:system_mail_t tcontext=root:object_r:mail_spool_t
tclass=file

avc:  denied  { remove_name } for  pid=6848 exe=/usr/sbin/postdrop
name=964455.6848 dev=dm-5 ino=34911 scontext=root:system_r:system_mail_t
tcontext=system_u:object_r:mail_spool_t tclass=dir

avc:  denied  { rename } for  pid=6848 exe=/usr/sbin/postdrop
name=964455.6848 dev=dm-5 ino=34911 scontext=root:system_r:system_mail_t
tcontext=root:object_r:mail_spool_t tclass=file

avc:  denied  { write } for  pid=6848 exe=/usr/sbin/postdrop
path=/var/spool/postfix/maildrop/11B20885F dev=dm-5 ino=34911
scontext=root:system_r:system_mail_t tcontext=root:object_r:mail_spool_t
tclass=file

avc:  denied  { setattr } for  pid=6848 exe=/usr/sbin/postdrop
name=11B20885F dev=dm-5 ino=34911 scontext=root:system_r:system_mail_t
tcontext=root:object_r:mail_spool_t tclass=file

avc:  denied  { getattr } for  pid=6848 exe=/usr/sbin/postdrop
path=/var/spool/postfix/public/pickup dev=dm-5 ino=34827
scontext=root:system_r:system_mail_t
tcontext=system_u:object_r:mail_spool_t tclass=fifo_file

avc:  denied  { write } for  pid=6848 exe=/usr/sbin/postdrop name=pickup
dev=dm-5 ino=34827 scontext=root:system_r:system_mail_t
tcontext=system_u:object_r:mail_spool_t tclass=fifo_file

HTH in finding a solution.

Regards,

Ranbir

-- 
Kanwar Ranbir Sandhu
Linux Consultant
Systems Aligned Inc.
www.systemsaligned.com

[Kanwar Ranbir Sandhu]

On Wed, 2005-02-02 at 12:42 -0500, Daniel J Walsh wrote:
>  For the time being you might want to 
>  change the
>  turn httpd transitioning off.
>  
>  setsebool -P httpd_disable_trans 1 
I gave that a shot, but it doesn't work.  A denial is still reported:

avc:  denied  { search } for  pid=6904 exe=/usr/sbin/sendmail.postfix
name=postfix dev=dm-5 ino=34833 scontext=root:system_r:system_mail_t
tcontext=system_u:object_r:mail_spool_t tclass=dir

BTW, the error reported in /var/log/maillog is this:

postfix/sendmail[6904]: fatal: chdir /var/spool/postfix: Permission
denied

Email is making it's way into RT because tickets are being created.
It's just the auto replies from RT that aren't making it out.
Basically, RT is not being allowed to SEND email.

Since I'm still running tests on RT (just upgraded), I'm going to set
SElinux to permissive mode.  I'm sure I'm going to run into other
problems with selinux.

Regards,

Ranbir

-- 
Kanwar Ranbir Sandhu
Linux Consultant
Systems Aligned Inc.
www.systemsaligned.com

[Daniel J Walsh]

Kanwar Ranbir Sandhu wrote:

> On Wed, 2005-02-02 at 12:42 -0500, Daniel J Walsh wrote:
>   
>
> >For the time being you might want to 
> >change the
> >turn httpd transitioning off.
> >
> >setsebool -P httpd_disable_trans 1
> >    
> >
>
> I gave that a shot, but it doesn't work.  A denial is still reported:
>
> avc:  denied  { search } for  pid=6904 exe=/usr/sbin/sendmail.postfix
> name=postfix dev=dm-5 ino=34833 scontext=root:system_r:system_mail_t
> tcontext=system_u:object_r:mail_spool_t tclass=dir
>
> BTW, the error reported in /var/log/maillog is this:
>
> postfix/sendmail[6904]: fatal: chdir /var/spool/postfix: Permission
> denied
>
> Email is making it's way into RT because tickets are being created.
> It's just the auto replies from RT that aren't making it out.
> Basically, RT is not being allowed to SEND email.
>
> Since I'm still running tests on RT (just upgraded), I'm going to set
> SElinux to permissive mode.  I'm sure I'm going to run into other
> problems with selinux.
>
> Regards,
>
> Ranbir
>
>   
>  
There is a bug in targeted policy that allows the system to transition 
from unconfined_t to httpd_sys_script_t even
if httpd_disable_trans is set. 

selinux-policy-targeted-1.17.30-2.76  should fix this for FC3
selinux-policy-targeted-1.21.8.3 should fix this for rawhide

both are available on
ftp://people.redhat.com/dwalsh/SELinux/{FC3,Fedora}

[Kanwar Ranbir Sandhu]

On Thu, 2005-03-02 at 10:24 -0500, Daniel J Walsh wrote:
>  There is a bug in targeted policy that allows the system to
> transition 
>  from unconfined_t to httpd_sys_script_t even
>  if httpd_disable_trans is set. 
>  
>  selinux-policy-targeted-1.17.30-2.76  should fix this for FC3 
I installed that after updating my system with 
selinux-policy-targeted-1.17.30-2.75, but I didn't see a change.  I
still got the same denials.

I've been running in permissive mode, and so far a few other denials
have popped up (denials for scripts trying to write directories). I've
been able to resolve them by changing the type in the target security
context.

When you want me to try something out, let me know.

Regards,

Ranbir
-- 
Kanwar Ranbir Sandhu
Linux Consultant
Systems Aligned Inc.
www.systemsaligned.com