Gene Heskett wrote:
On Tuesday 25 April 2006 07:50, Paul Howarth wrote:
[...]
The only place I'll fault the instructions in the above link is that
in the case of FC5, one must change the use of the ~/downloads
directory quoted every so often to be /usr/src/redhat in actual
fact, then everything Just Works(TM).
Hmm, the ~/download directory just represents wherever your browser
puts stuff you've downloaded (sometimes that would be ~/Desktop).
/usr/src/redhat is a very strange place for that to be since that's
only writable by root. You don't run a browser as root do you?
Yes and no, mostly yes. But I'm behind a pretty bulletproof firewall
here at home too. The whole point was that I had to move it there
because the make script generated was apparently hard coded to look for
its stuff in /usr/src/redhat/RPMS,SOURCE etc, tree that was reported by
the dying build, and that was already pre-constructed by the FC5
install. It wouldn't build if not there, and I don't know if being
root or not, I was, would have effected that outcome. So I just moved
it all to where it wanted it to be. The end result also works fine as
uid 500 too.
It is because you ran it as root. The instructions actually go to some
length to support building the package as a non-root user, and in fact
the linked page on creating an RPM-build environment mentions some
reasons why building packages as root is a bad idea.
In this case the result is the same and no harm is done, but I'd try to
avoid that in future and in fact do as little as possible as root,
regardless of how good your firewall is.
'scuse me, but these manpages suck dead toads through soda straws!
(Thats plagerizing a longtime friend of mine you all know)
They seriously need a rewrite in much plainer language. These are
concise to the point of obtuse. WTDO=Way Too Damned Obtuse.
Have to agree there.
Who wrote them?, I wanna throw something at that person.
IIRC one of the things the author did actually manage to include was his
name :-)
SELinux file contexts get set in one of two ways.
1. By an SELinux-aware application manually setting the context based
on the pathname of the object concerned. This is, for example, what
rpm does when new packages are installed, and it uses the file
contexts configured in the SELinux policy you're using. The command
"semanage fcontext -l" lists a bunch of regular expressions matching
pathnames, which rpm searches to find the correct context to use for
each file/directory etc. being installed. The same process happens if
you use "restorecon" or relabel the entire system.
2. By the kernel when a file/directory etc. is created. This does not
use pathnames at all; instead, the context is based on the SELinux
domain that the process is running in and the file context of the
inode for the directory that the item is to be created in. The
contexts to be used in these cases are defined in the SELinux policy
and can be changed by building and installing an SELinux policy
module. But that's outside the scope of this discussion.
Not to mention outside my ken.
The latter is the "normal" and "preferred" way to establish contexts
because pathname-based contexts are a bad idea generally (e.g.
supposing you have multiple links to the same file using different
paths - which should be used to set the context?). The former method
is there so that an initial sane state can be created or reverted to
in the event of policy changes, cock-ups etc.
So, what you're doing with "chcon" is manually setting file context,
just like rpm would do, except you're setting the context to the value
you believe to be correct instead of the one the policy writer
believes to be correct. Since the policy writer may be ignorant of
your requirements, this is a good thing.
How, when you do a "restorecon" or "relabel", what you're doing is
saying "I've got a bunch of files with contexts that may or may not be
correct fow whatever reason, and I'd like them restored to the system
default context". So that overrides the changes you made manually
using "chcon". Well, actually that doesn't happen if the type you've
used is defined as a "customisable type" - that will not be touched,
but that's a side issue here.
:)
Now if you're really sure that you've got the right contexts, you can
actually change the policy itself so that a "restorecon" or "relabel"
will restore the contexts to the ones you've specified. This is done
using semanage to add additional file context objects to the policy.
It doesn't change any file contexts itself, it just sets up the
defaults that will be used if "restorecon" is used or you relabel the
system.
And you obviously have a much better grasp of this than I, thanks to
those wholely inadequate manpages. :(
I only grasped this myself fairly recently. However, the FC5 SELinux
documentation is a vast improvement on that available for earlier
releases, at least if you know where to look for it.
http://fedoraproject.org/wiki/SELinux is a decent starting point.
Paul.
Paul.
