#acl PaulHowarth:read,write,admin,revert,delete All:read

=== Thursday 29th April 2010 ===

==== Local Packages ====

 * New package `perl-Compress-Raw-Lzma` (2.027); I had to patch this to get it to build against a recent `xz` ([[CPAN:57080|CPAN RT#57080]])
 * New package `perl-IO-Compress-Lzma` (2.027)

I also updated `curl` to patch the test suite to get it to be able to start the OpenSSH server on a system with SELinux in enforcing mode (but only for an ''unconfined'' user) - [[RedHatBugzilla:521087|Bug #521087]]. Now it might seem strange that this would be a problem for an ''unconfined'' user but OpenSSH is an SELinux-aware application, and takes different code paths depending on whether SELinux is enforcing or not. When starting a new session, it needs to set the correct SELinux security context for the session, and the possible options to choose from a different depending on the context OpenSSH is running in. When it's running unconfined, it doesn't get a valid context to start a session, and so it bombs out. So the trick is to get it to run in the regular `sshd_t` security context. 

Processes can transition between SELinux domains when they `exec` another process but not all `exec`s cause domain transitions.
In the `curl` test suite running as `unconfined_t`, the `sshd` daemon (file content `sshd_exec_t`) is started but no
domain transition is defined for that in policy so `sshd` continues running as `unconfined_t`. My patch adds an intermediate
process (a perl script called `initdaemon.pl`, which is labelled with a file context of `initrc_exec_t`) that is used to
start `sshd`. Now, when a process running in `unconfined_t` executes a file labelled `initrc_exec_t`, it transitions to
the `initrc_t` domain, which is what system initscripts run as. And when that process subsequently runs `sshd` (file content `sshd_exec_t`),
it transitions to `sshd_t` as desired.

That gets us part way there. The next problem is that `sshd_t`, being a confined domain, can no longer write its
log files or PID files into the directory the `curl` build is running in (typically a user's home directory, or
a subdirectory of it) because SELinux prevents the system process trampling over user data. So the other part of the
patch is to:
 * Create a new subdirectory for the test suite to write PID files to, label it appropriately by using the same SELinux context type as the `/var/run` directory where system PID files usually reside, and persuade the test suite to put PID files in that directory
 * Make sure that the file that records the output of the `sshd` process is labelled with an SELinux context type that `sshd_t` can write to, for which I copied the context type of `~/.ssh` (`home_ssh_t` on F-12)

The changes I've made don't seem to have broken anything else, so I'll look to push it upstream.
First though, Kamil, the Fedora `curl` maintainer, will try it out on a variety of systems (both with and without SELinux)
to check that it works as advertised and doesn't cause any regressions, which should happen some time next week.

----