[Bug 1121601] Review Request: rt - request tracker

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



https://bugzilla.redhat.com/show_bug.cgi?id=1121601



--- Comment #38 from Alex Vandiver <alexmv@xxxxxxxxxxxxxxxxx> ---
(In reply to Jason Tibbitts from comment #37)
> We could pretty easily mess with the packaging of that perl module if any of
> this makes a difference. It appears that it's used only by publican (our
> docbook publication system) so we'd have to talk to them.  Maybe someone
> just needs to fork the module.

Unfortunately, all of the perl-based HTML -> text converters seem to be
poorly-mainatined, and prone to crashing on fairly simple input.  As a result,
RT 4.2 is moving towards instead adding an optional dependency on
HTML::FormatExternal, which shells out to w3m or elinks -- we're not interested
in forking, developing, and supporting a text-based HTML rendering engine when
there already exist several in the wild (aka "browsers").  I expect that 4.4
will drop HTML::FormatText::WithTables::AndLinks entirely.

> And selinux would definitely keep the webserver from writing to an unlabeled
> location under /var (or anywhere else; the web server is rather strictly
> confined).  Now, when I look in the current F21 policy, I see the following
> rt-related labels:
> 
> /var/cache/rt(3|4)(/.*)?                           all files         
> system_u:object_r:httpd_cache_t:s0
> 
> /var/lib/rt(3|4)/data/RT-Shredder(/.*)?            all files         
> system_u:object_r:httpd_var_lib_t:s0
> 
> Which makes it pretty obvious where the problems lie.
> 
> Since we're using "rt" and not "rt4" for these directories, none of this
> matches, and even if it were fixed, the labeling for /var/lib/rt would be a
> bit too restrictive, I think.
> 
> The selinux folks are very happy to tweak policy and they usually do it
> rather quickly.  If we could just get a list of everywhere rt is expected to
> write, it would be pretty easy to get them to patch things up.  Alex, would
> you happen to know that off the top of your head?

/var/lib/rt needs to be writable for SQLite; the database is a file named
/var/lib/rt/rt4  (assuming that $DatabaseName is set to rt4).  Since SQLite is
defined to be "not for production" there's some slack here in how much we care,
though.

If file-based logging is enabled, writing to /var/log/rt is also necessary. 
The above rules (fixed for "rt" not "rt4") cover Mason's cache.  The shredder
directories also need to be writable.  I _believe_ that to be sufficient -- in
the past we've simply set httpd_sys_rw_content_t on all of /opt/rt4/var, which
is a big-ish hammer.

 - alex

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
_______________________________________________
package-review mailing list
package-review@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/package-review





[Index of Archives]     [Fedora Legacy]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]