Jeff Spaleta wrote:
On Jan 22, 2008 7:52 AM, Casey Dahlin <cjdahlin@xxxxxxxx> wrote:
We're advertising it in a very public way. More people are expecting it
to work.
But we aren't using it internally, we aren't dogfooding it with our
spins, and I want to make sure Valent and anyone reading the thread
understands that. My reading of Valent's comment informed me that he
was assuming we were seeing these problems as part of spin release and
implied an assumption that we were using revisor. We aren't.
Now that being said, I think any spin generation toolchain which we
are offering, should be packaged in a way that informs people that
selinux needs to be disabled to use correctly.
And since I don't think spin creation falls into a desktop usage case
of any rational merit, but falls instead into development usage, then
I don't think such a tool should automatically disable selinux even
temporarily.
Selinux when interacting with any chroot-like apparatus is still a
problem.
Except for perhaps *cough* qfakeroot
(disclaimer: the below urls are about 12 hours old, and the tools in
question are still a couple days away from being actually testable from
the tutorial which also is only about 12 hours old)
http://filteredperception.org/smiley/projects/viros/viros-0.5/tools/scripts/qfakeroot.html
http://filteredperception.org/smiley/projects/viros/docs/faq/index.html#viros_differences_from_livecdtools
Note, that one reason I went down this rather convoluted non-traditional
architecture for a compose tool, was to quite explicitly not have any
dependence on host build system state such as selinux (and not require
root priveleges to run is the other related big one)
-dmc
Perhaps its time to take stock of all the packages that rely
on chroot-like behavior which are similarly affected by selinux, so
that a common technical solution can be found and applied.
-jef
-jef
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
