Hmm, it looks like a context specification for /var/run/mod_fcgid(/.*)? has appeared in the main selinux-policy package that conflicts with the one in the mod_fcgid-selinux package. Whilst the message is harmless, it's annoying.

I see two options here:
1. Tweak mod_fcgid-selinux to specify the file contexts differently so that they silently override the base policy, or
2. Move towards incorporating the mod_fcgid-selinux policy into the base policy package, and obsolete mod_fcgid-selinux.

Given that mod_fcgid-selinux seems to be quite stable (though I've no idea how many people actually use it), I think the latter option would be the better one.

Thoughts Dan?

Yes lets role it into the base policy.

OK, can you pull the module source from CVS (the mod_fcgid package), or do you want me to attach it to this ticket?

Let me know which package release this is going into and I'll do a version of mod_fcgid without the -selinux subpackage and add Obsoletes/Conflicts like:

Obsoletes: mod_fcgid-selinux < %{version}-%{release}
Conflicts: selinux-policy < version-release-containing-this-policy

Are you going to do updates for F8, F9, and Rawhide for this?

After looking at your policy, I am not sure we want to add it.  cgi scripts should run as httpd_sys_script_t whether they are run traditionally or in fastcgi.

So shouldn't fastcgi just be labeled httpd_sys_script_exec_t?

It could be; I initially separated them out because FastCGI needed a few extra allow rules that weren't in the regular sys_script policy and it was an opportunity to separate the scripts I was using into different domains.

I've no objection to merging the two as long as the extra rules are included.

What are the extra rules?

I really am not an expert on apache or fast-cgi.  What would fast-cgi do if it came upon a script labeled httpd_bugzilla_script_exec_t, can we get it to transition to httpd_bugzilla_script_t, like httpd_t would?  Maybe with a boolean?

FastCGI processes are like regular CGIs except that they are longer-lived and serve multiple requests. Instead of communicating with httpd over stdin, they use unix-domain sockets.

The rules I have that aren't directly cribbed from the httpd_sys_script policy (though some might be there now) are:

kernel_read_kernel_sysctls(httpd_fastcgi_script_t)

# Allow FastCGI applications to do DNS lookups
sysnet_dns_name_resolve(httpd_fastcgi_script_t)

==> those two might be in the regular policy by now?

# Allow FastCGI applications to live alongside regular CGI apps
allow httpd_fastcgi_script_t httpd_sys_script_exec_t:dir { search_dir_perms };
allow httpd_fastcgi_script_t httpd_sys_content_t:dir { search_dir_perms };

==> Those shouldn't be needed if merging sys and fastcgi

# Allow FastCGI applications to read the routing table
allow httpd_fastcgi_script_t self:netlink_route_socket { r_netlink_socket_perms };

==> Virtually everything seems to need that...

# Allow httpd to create and use files and sockets for communicating with mod_fcgid
manage_files_pattern(httpd_t,httpd_fastcgi_var_run_t,httpd_fastcgi_var_run_t)
manage_sock_files_pattern(httpd_t,httpd_fastcgi_var_run_t,httpd_fastcgi_var_run_t)
setattr_dirs_pattern(httpd_t,httpd_fastcgi_var_run_t,httpd_fastcgi_var_run_t)

==> can map httpd_fastcgi_var_run_t to httpd_var_run_t and it should just work?

# Allow httpd to read httpd_fastcgi_content_t
allow httpd_t httpd_fastcgi_content_t:dir list_dir_perms;
read_files_pattern(httpd_t,httpd_fastcgi_content_t,httpd_fastcgi_content_t)
read_lnk_files_pattern(httpd_t,httpd_fastcgi_content_t,httpd_fastcgi_content_t)

==> should just work after mapping httpd_fastcgi_content_t to httpd_sys_content_t?

# Allow FastCGI applications to listen for FastCGI requests on their
# sockets and respond to them
allow httpd_fastcgi_script_t httpd_t:unix_stream_socket { rw_stream_socket_perms };

==> At last, the "extra rules" ;-)

# These are probably leaked file descriptors
dontaudit httpd_t devpts_t:chr_file ioctl;
dontaudit httpd_fastcgi_script_t httpd_log_t:file ioctl;

==> Apache don't seem to regard these as bugs, do they?


Regarding bugzilla, a FastCGI version of it would be a different script, and would probably need the extra rules for FastCGI adding to the bugzilla policy too.

Any news on the status of this bug ?

FastCGI policy is going to get merged into the standard httpd policy real soon now...

Fixed in selinux-policy-3.0.8-122.fc8

I trust the same fix will be applied in F-9 and Rawhide too? I'd like to know the version/releases for those too so I can build new mod_fcgid packages without the -selinux subpackages and have them conflict with selinux-policy packages that don't contain the merged policy.

I am obsoleting your package, so I don't think you need to do anything.

Other then stop shipping it.

selinux-policy-3.5.13-3.fc10
selinux-policy-3.3.1-104.fc9

I need to do a rebuild to remove the -selinux subpackage and to modify the SELinux advice currently in a README in that package (and move that README to the main package). The advice in that README will be wrong if the user has a version of selinux-policy prior to the ones with the fixes, hence my desire to add versioned conflicts. I can't add a versioned dependency instead because that would then require selinux-policy for a package that should work just fine on a system with no SELinux installed.

Yes, but selinux-policy-targeted will cause you -selinux package to be removed.

Yes, but that's not the problem I'm trying to solve. I'm trying to avoid the situation where someone has got a system that's not fully up to date (e.g. fresh install) and just installs the new mod_fcgid package and expects it to work with SELinux, which it won't unless selinux-policy is updated. I'm trying to enforce a policy update but without actually adding a dependency on policy basically.

Will the change make it to EL-5 eventually? I have an EPEL-5 version that includes the policy module, which I guess will need to stay around a while yet.

mod_fcgid-2.2-6.fc8 has been submitted as an update for Fedora 8.
http://admin.fedoraproject.org/updates/mod_fcgid-2.2-6.fc8

mod_fcgid-2.2-6.fc8 has been pushed to the Fedora 8 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update mod_fcgid'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F8/FEDORA-2008-9164

mod_fcgid-2.2-6.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.