Serving Mercurial Repositories
by Jonathan Stott
Hi
I'm quite new to Fedora (and SELinux) but I've been using linux for
some time and one of the tools I use more or less daily is the
mercurial scm. I would like to share (read only) versions of some of
the repositories I work on to other members of my group. The
mercurial team provide a script to do this which (when configured via
a simple file) can read the configured repository directories
(scattered about my home directory) and from there generate the web
interface.
Currently this fails, because I have policies configured such that
lighttpd can only read from the public_html directory of home
directories and I would prefer not to have to change things so that it
can read all of my home directory. I would also prefer to avoid the
need to have 2 copies of the repository on the system, one in my home
directory and one somewhere else (say /var/hg ) that I can let
lighttpd read as it desires, since this brings about synchronisation
issues.
I thought a solution might be to write a policy for mercurial so that
all repos are created with a 'mercurial_repo_t' type or similar and
then allow the lighttpd_t context to read them (it can already search
home directories) but I am unsure of how to go about implementing such
a policy, or how it might be done better.
Any advice would be appreciated,
Jon
16 years, 4 months
Re: Enforced Selinux prevents booting
by Antonio Olivares
--- Antonio M <antonio.montagnani(a)gmail.com> wrote:
> I updated to kernel-2.6.24-0.107.rc5.git3.fc9,
> selinux-policy-3.2.4-2.fc9 and related packages.
>
> I switched to enforced and I rebooted: I get a
> kernel panic, I don't
> think it is connected as I get same result with
> older kernels.
>
> Any bug connected or shall we file a new one? (I
> didn't find any bug
> in my bugzilla query that could play with this
> problem..)
>
> --
> Antonio Montagnani
> Skype : antoniomontag
>
> --
I agree with you here 100%. To login, you have to at
least use enforcing=0, otherwise your system will
hang. I logged into level 3 and login, and then I see
the login again and it cycles recursively if I leave
selinux on in enforcing mode. Selinux is misbehaving :(
____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
16 years, 4 months
OLS CfP
by James Morris
The OLS CfP is open:
http://www.linuxsymposium.org/2008/cfp.php
I think it would be great if we could get some SELinux
tutorials/talks/BoFs happening with a focus on usability and recent
advances. One of the problems we face now is that people have had bad
experiences with earlier versions of SELinux, and understandably not then
closely followed subsequent developments.
e.g.
- tutorial ideas:
- "Developing SELinux policy with SLIDE"
- "How to manage SELinux servers" (with modern techniques)
- "Using xguest: kiosks, consumer electronics, ..."
- A BoF session for various distro integration efforts might be useful, as
there seems to be more happening again outside of Fedora/RH, and I'm sure
there are things we can all help each other with, wishlists for upstream
etc.
The CfP closes on Feb 1st 2008.
- James
--
James Morris
<jmorris(a)namei.org>
16 years, 4 months
RE: [F8] setroubleshoot running at 85-95% of CPU
by Dan Thurman
John Dennis wrote"
>File a bug report for starters. It would really help to get some
>diagnostic information. To do this edit
>/etc/setroubleshoot/setroubleshoot.cfg, find the section in
>the cfg file
>label setroubleshootd_log, in that section change the value of
>level to
>debug and then restart setroubleshootd with
>
>/sbin/service setroubleshoot restart
>
>After it misbehaves stop the service with
>
>/sbin/service setroubleshoot stop
>
>Then attach the logfile /var/log/setroubleshoot/setroubleshootd.log to
>the bug report.
Ok, I have set the level = debug, started setroublesootd and tail'ed
/var/log/setroubleshootd/*.log for about 15-30 minutes and I see
nothing at all. Not a single entry was logged.
I tried to bring up the sealert (or Applications->System-Tools->
SELinux Troubleshooter) and I was not able to get/see the gui
for this application to even come up. It refuses to display
the gui.
Any ideas?
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.503 / Virus Database: 269.17.1/1183 - Release Date: 12/13/2007 9:15 AM
16 years, 4 months
[F8] setroubleshoot running at 85-95% of CPU
by Dan Thurman
This thread was originally posted at fedora-list, but other
posters recommended that I repost this thread here in this
list, although cleaned up.
For awhile, it seemed that I was getting regular sealert warnings
(the "star" in notification taskbar) but now I no longer receive it.
I noticed that setroubleshoot was running at 85-95% of CPU load so
I killed it along with sealert processes and that brought the CPU
load WAY down.
I have removed the setroubleshoot packages and re-installed it.
It did not remove the problem.
At this point, I have disabled the setroubleshootd service and my
CPU is now quiet.
What can I do to fix or analyze this problem?
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.503 / Virus Database: 269.17.1/1183 - Release Date: 12/13/2007 9:15 AM
16 years, 4 months
Python httpd permission denied
by Mark Knoop
I am running a python script as Apache CGI in
~/www/sitename/python/index.py. All was working fine in F7 and F8 until
selinux-policy-3.0.8-58 arrived in updates. I've only now had time to
look at this and am not sure what the problem might be.
Apache error log reads:
[error] [client 127.0.0.1] python: can't open file
'/home/user/www/sitename/python/index.py': [Errno 13] Permission denied
/var/log/messages:
setroubleshoot: #012 SELinux is preventing the python from using
potentially mislabeled files <Unknown> (user_home_dir_t).#012 For
complete SELinux messages. run sealert -l
3506ffc2-aeb9-493c-b2f1-f579479c7ed5
The script is labelled user_u:object_r:httpd_sys_content_t, I've also
tried httpd_sys_script_exec_t but get the same error.
Labelling as httpd_unconfined_script_exec_t DOES work, as do other
(non-CGI) pages. There don't seem to be any changes in the changelogs
for -57 and -58 which would affect this... any ideas?
* Fri Nov 16 2007 Dan Walsh <dwalsh(a)redhat.com> 3.0.8-58
- Allow nmbd to list inotifyfs_t
- Dontaudit consolekit access to user homedir
- dontaudit nscd getserv and shmemserv
- Allow rsync_t dac overrides
- Allow xfs_t to listen to sockets
* Fri Nov 16 2007 Dan Walsh <dwalsh(a)redhat.com> 3.0.8-57
- Allow lvm to search mnt
- Add booleans for xguest account
xguest_mount_media
xguest_connect_network
xguest_use_bluetooth
--
Mark Knoop
16 years, 4 months
kde4/selinux love
by Rex Dieter
kde4 could use some serious selinux attention/love, looking for
help/volunteers.
First off, any help to address:
"Selinux is preventing kdm to login a user"
http://bugzilla.redhat.com/421951
would be greatly appreciated.
What's worse, (I could be wrong, have only tested it now 3 times), is that a
kde4 desktop/login isn't functional even with enforcing=0, but selinux=0 is
required. eek.
-- Rex
16 years, 4 months
FC8: selinux stops cupsd from starting
by Matt Thompson
I am having a problem with cupsd on my FC8 box. Namely, it only seems
to want to start on reboot. If I try to start it later I get:
# service cups start
Starting cups: /bin/bash: /usr/sbin/cupsd: Permission denied
[FAILED]
and then audit.log sayeth:
type=SELINUX_ERR msg=audit(1197478409.420:673): security_compute_sid:
invalid context user_u:system_r:cupsd_t:s0-s0:c0.c1023 for
scontext=user_u:system_r:initrc_t:s0
tcontext=system_u:object_r:cupsd_exec_t:s0 tclass=process
This seems to be the same bug as in #390391:
https://bugzilla.redhat.com/show_bug.cgi?id=390391
but none of the fixes in that seemed to work.
More detail can be found at the bug, but I thought I'd ask here in case
the answer was well known and my bugzilla-search-fu was lacking.
Thanks for any help,
Matt Thompson
--
Matt Thompson, PhD
Naval Research Laboratory
202-767-2160
16 years, 4 months
