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
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.
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
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.
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
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 :/
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
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@systemsaligned.comCould 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
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
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?
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
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 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.
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 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
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
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 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
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
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
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 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}
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
selinux@lists.fedoraproject.org
-
Colin Walters -
Daniel J Walsh -
Kanwar Ranbir Sandhu