slow speed of selinux commands

[Fulko Hew]

On Mon, Sep 19, 2011 at 4:01 PM, Fulko Hew <fulko.hew at gmail.com> wrote:
> On Mon, Sep 19, 2011 at 3:32 PM, Eric Paris <eparis at redhat.com> wrote:
>> On Mon, 2011-09-19 at 14:49 -0400, Fulko Hew wrote:
>>
>>> If so... why use chcon versus the semanage/restorecon technique?
>>> or if my assesement is wrong... can someone point me to a better
>>> explanation/tutorial?
>
> ... snip ...
>
>> So semanage+restorecon == will last, chcon == will likely get blown away
>> and make you angry later.
>
> Thanks for confirming that for me.

Sorry to take a long time for a further followup...
I made the changes to my RPM spec file, and it works, but...

The processing sure takes a long time...
Whereas 'installing' the files is a quick procedure (seconds),
my subsequent selinux commands take _minutes_ to process.

Surely the other packages can't be using this combo of commands
inside their spec files to handle selinux mode/attribute setting
during installation (because they don't take this long to install).

There has to be a better way/faster way.

What I have right now is:

if [ -x /usr/sbin/selinuxenabled ] && selinuxenabled; then # if it exists
and can be run
    setsebool -P httpd_can_network_connect=1                # then enable
this ability
   setsebool -P httpd_enable_cgi=1                         # this one should
normally be on...
fi                                                         # but force it
because _we_ need it!

if semanage fcontext -a -t httpd_sys_script_exec_t
"/var/www/html/nia/scripts/.*" 2>/dev/null; then
   restorecon -v /var/www/html/nia/scripts/* 2>/dev/null
fi
if semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/html/nia/tmp"
2>/dev/null; then
    restorecon -v /var/www/html/nia/tmp 2>/dev/null
fi
     # needed for RHEL 5.6 & GraphViz access to the fonts
if semanage fcontext -a -t httpd_sys_content_t "/var/cache/fontconfig/.*"
2>/dev/null; then
    restorecon -v /var/cache/fontconfig/* 2>/dev/null
fi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-list/attachments/20111012/eb665664/attachment.html>