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. >> And I have yet another very big grin on my face for a few minutes, >> till I run into the next showstopper anyway. >> >> Which isn't this, but this is a slight worry from the log: >> >> Apr 24 21:34:07 diablo kernel: hdc: cdrom_pc_intr: The drive appears >> confused (ireason = 0x01) >> Apr 24 21:34:09 diablo kernel: hdc: cdrom_pc_intr: The drive appears >> confused (ireason = 0x01) >> >> There is no disk in the drive, and its been reading disks just fine. > >Could be a hardware issue. >http://lists.xiph.org/pipermail/paranoia/2004-May/001271.html > >>>> Now, maybe I'm slow this morning, but my reading of the semanage >>>> manpage makes no mention of setting a 'default' that a relabel >>>> will leave alone. >>> >>> Using semanage you can change policy for file contexts amongst >>> other things. This affects the contexts applied to files using >>> restorecon etc. >> >> Are you saying that if I change it with chcon, its temporary, but if >> I change it with semanage its permanent? >> >> '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. >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. :( >Paul. -- Cheers Paul, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
