FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Directory

 
 
LinkBack Thread Tools
 
Old 07-15-2010, 04:12 PM
Aaron Hagopian
 
Default Announcing 389 Directory Server 1.2.6 Release Candidate 3

I upgraded my fedora 13 x86_64 machine to the RC3 using the rpms in updates-testing and now I cannot start the admin server with selinux enabled. *I am attaching the selinux message. *It does start when I disable selinux.



On Tue, Jul 6, 2010 at 2:38 PM, Rich Megginson <rmeggins@redhat.com> wrote:


The 389 team is pleased to announce the availability of Release

Candidate 3 of version 1.2.6. *This release has a few bug fixes.



***We need your help! *Please help us test this software.*** *It is a

release candidate, so it may have a few glitches, but it has been tested

for regressions and for new feature bugs. *The Fedora system

strongly encourages packages to be in Testing until verified and pushed

to Stable. *If we don't get any feedback while the packages are in

Testing, the packages will remain in limbo, or get pushed to Stable.



The more testing we get, the faster we can release these packages to

Stable. *See the Release Notes for information about how to provide

testing feedback (or just send an email to

389-users@lists.fedoraproject.org).



The packages that need testing are:

* 389-ds-base-1.2.6.rc3 - 389-ds-base



More information

* Release Notes - http://port389.org/wiki/Release_Notes

* Install_Guide - http://port389.org/wiki/Install_Guide

* Download - http://port389.org/wiki/Download



=== Bugs Fixed ===

This release contains a couple of bug fixes. *The complete list of bugs

fixed is found at the link below. *Note that bugs marked as MODIFIED

have been fixed but are still in testing.

* Tracking bug for 1.2.6 release -

https://bugzilla.redhat.com/showdependencytree.cgi?id=543590&hide_resolved=0

** *Bug 606920 - anonymous resource limit - nstimelimit - also applied

to "cn=directory manager"

** Bug 604453 - SASL Stress and Server crash: Program quits with the

assertion failure in PR_Poll

** Bug 605827 - In-place upgrade: upgrade dn format should not run in

setup-ds-admin.pl

** Bug 578296 - Attribute type entrydn needs to be added when subtree

rename switch is on

** Bug 609256 - Selinux: pwdhash fails if called via Admin Server CGI

** Bug 603942 - null deref in _ger_parse_control() for subjectdn



--

389 users mailing list

389-users@lists.fedoraproject.org

https://admin.fedoraproject.org/mailman/listinfo/389-users




Summary:

SELinux is preventing /usr/sbin/httpd.worker from using potentially mislabeled
files /etc/dirsrv.

Detailed Description:

SELinux has denied the httpd.worker access to potentially mislabeled files
/etc/dirsrv. This means that SELinux will not allow httpd to use these files. If
httpd should be allowed this access to these files you should change the file
context to one of the following types, httpd_bugzilla_rw_content_t,
httpd_nutups_cgi_script_exec_t, var_log_t, setrans_var_run_t, sysctl_crypto_t,
samba_var_t, pki_ra_var_lib_t, pki_ra_var_run_t, avahi_var_run_t, sysctl_t,
abrt_t, bin_t, lib_t, net_conf_t, mnt_t, httpd_cvs_rw_content_t,
httpd_git_rw_content_t, httpd_nagios_content_t, httpd_sys_rw_content_t,
httpd_w3c_validator_content_t, root_t, tmp_t, httpd_nagios_rw_content_t, usr_t,
var_t, public_content_t, httpd_nutups_cgi_rw_content_t,
httpd_cobbler_script_exec_t, anon_inodefs_t, httpd_sys_content_t,
sysctl_kernel_t, var_lib_nfs_t, home_root_t, httpd_modules_t,
httpd_smokeping_cgi_script_exec_t, httpd_git_content_t, httpd_user_content_t,
mysqld_var_run_t, httpd_var_lib_t, httpd_var_run_t, device_t, nscd_var_run_t,
nslcd_var_run_t, pki_ra_log_t, sssd_var_lib_t, var_t, httpd_squid_rw_content_t,
httpd_apcupsd_cgi_content_t, etc_t, pki_tps_log_t, mysqld_db_t, proc_t,
httpd_prewikka_content_t, gitosis_var_lib_t, httpd_smokeping_cgi_rw_content_t,
httpd_apcupsd_cgi_rw_content_t, httpd_munin_content_t, httpd_squid_content_t,
pki_tps_var_lib_t, pki_tps_var_run_t, httpd_awstats_script_exec_t,
httpd_smokeping_cgi_content_t, mailman_archive_t, httpd_cvs_content_t,
httpd_sys_content_t, logfile, public_content_rw_t, rpm_script_tmp_t,
mailman_data_t, security_t, httpd_munin_script_exec_t, var_lock_t, sysctl_t,
httpd_w3c_validator_script_exec_t, system_dbusd_var_lib_t,
system_dbusd_var_run_t, bin_t, cert_t, httpd_prewikka_rw_content_t,
httpd_user_script_exec_t, httpd_cobbler_content_t, squirrelmail_spool_t,
httpd_t, httpd_bugzilla_content_t, lib_t, mnt_t, tmp_t, usr_t, var_t,
httpd_apcupsd_cgi_script_exec_t, cobbler_var_lib_t, httpd_nagios_script_exec_t,
rpm_tmp_t, nagios_etc_t, nagios_log_t, var_run_t, sssd_public_t,
httpd_squid_script_exec_t, httpd_awstats_rw_content_t,
httpd_w3c_validator_rw_content_t, winbind_var_run_t, cluster_conf_t, autofs_t,
device_t, devpts_t, locale_t, likewise_var_lib_t, httpd_bugzilla_script_exec_t,
fonts_cache_t, etc_t, fonts_t, httpd_log_t, proc_t, sysfs_t, tmpfs_t,
httpd_awstats_content_t, var_lib_t, krb5_conf_t, httpd_user_rw_content_t,
httpd_config_t, httpd_nutups_cgi_content_t, sysctl_net_t, rpm_log_t,
httpd_cobbler_rw_content_t, httpd_prewikka_script_exec_t, calamaris_www_t,
httpd_munin_rw_content_t, var_spool_t, httpd_cache_t, httpd_tmpfs_t, udev_tbl_t,
httpd_tmp_t, httpd_sys_script_exec_t, iso9660_t, pki_tps_etc_rw_t,
smokeping_var_lib_t, httpd_git_script_exec_t, var_lib_t, var_run_t,
mysqld_etc_t, cvs_data_t, httpd_cvs_script_exec_t, configfile, pki_ra_etc_rw_t,
dbusd_etc_t, abrt_var_run_t, httpd_squirrelmail_t, httpd_bugzilla_ra_content_t,
httpd_bugzilla_rw_content_t, httpd_nutups_cgi_script_exec_t,
httpd_cvs_ra_content_t, httpd_cvs_rw_content_t, httpd_git_ra_content_t,
httpd_git_rw_content_t, httpd_nagios_content_t, httpd_sys_ra_content_t,
httpd_sys_rw_content_t, httpd_w3c_validator_content_t,
httpd_nagios_ra_content_t, httpd_nagios_rw_content_t,
httpd_nutups_cgi_ra_content_t, httpd_nutups_cgi_rw_content_t,
httpd_cobbler_script_exec_t, httpd_smokeping_cgi_script_exec_t,
httpd_git_content_t, httpd_user_content_t, root_t, nscd_var_run_t,
pcscd_var_run_t, httpd_squid_ra_content_t, httpd_squid_rw_content_t,
httpd_apcupsd_cgi_content_t, httpd_prewikka_content_t,
httpd_smokeping_cgi_ra_content_t, httpd_smokeping_cgi_rw_content_t,
httpd_apcupsd_cgi_ra_content_t, httpd_apcupsd_cgi_rw_content_t,
httpd_munin_content_t, httpd_squid_content_t, httpd_awstats_script_exec_t,
httpd_smokeping_cgi_content_t, httpd_cvs_content_t, httpd_sys_content_t,
httpd_munin_script_exec_t, httpd_w3c_validator_script_exec_t,
httpd_prewikka_ra_content_t, httpd_prewikka_rw_content_t,
httpd_user_script_exec_t, httpd_cobbler_content_t, httpd_bugzilla_content_t,
var_t, var_t, httpd_apcupsd_cgi_script_exec_t, httpd_nagios_script_exec_t,
httpd_squid_script_exec_t, httpd_awstats_ra_content_t,
httpd_awstats_rw_content_t, httpd_w3c_validator_ra_content_t,
httpd_w3c_validator_rw_content_t, httpd_bugzilla_script_exec_t,
httpd_awstats_content_t, httpd_user_ra_content_t, httpd_user_rw_content_t,
httpd_nutups_cgi_content_t, httpd_cobbler_ra_content_t,
httpd_cobbler_rw_content_t, httpd_prewikka_script_exec_t,
httpd_munin_ra_content_t, httpd_munin_rw_content_t, httpd_sys_script_exec_t,
httpd_git_script_exec_t, var_run_t, var_run_t, httpd_cvs_script_exec_t. Many
third party apps install html files in directories that SELinux policy cannot
predict. These directories have to be labeled with a file context which httpd
can access.

Allowing Access:

If you want to change the file context of /etc/dirsrv so that the httpd daemon
can access it, you need to execute it using semanage fcontext -a -t FILE_TYPE
'/etc/dirsrv'.
where FILE_TYPE is one of the following: httpd_bugzilla_rw_content_t,
httpd_nutups_cgi_script_exec_t, var_log_t, setrans_var_run_t, sysctl_crypto_t,
samba_var_t, pki_ra_var_lib_t, pki_ra_var_run_t, avahi_var_run_t, sysctl_t,
abrt_t, bin_t, lib_t, net_conf_t, mnt_t, httpd_cvs_rw_content_t,
httpd_git_rw_content_t, httpd_nagios_content_t, httpd_sys_rw_content_t,
httpd_w3c_validator_content_t, root_t, tmp_t, httpd_nagios_rw_content_t, usr_t,
var_t, public_content_t, httpd_nutups_cgi_rw_content_t,
httpd_cobbler_script_exec_t, anon_inodefs_t, httpd_sys_content_t,
sysctl_kernel_t, var_lib_nfs_t, home_root_t, httpd_modules_t,
httpd_smokeping_cgi_script_exec_t, httpd_git_content_t, httpd_user_content_t,
mysqld_var_run_t, httpd_var_lib_t, httpd_var_run_t, device_t, nscd_var_run_t,
nslcd_var_run_t, pki_ra_log_t, sssd_var_lib_t, var_t, httpd_squid_rw_content_t,
httpd_apcupsd_cgi_content_t, etc_t, pki_tps_log_t, mysqld_db_t, proc_t,
httpd_prewikka_content_t, gitosis_var_lib_t, httpd_smokeping_cgi_rw_content_t,
httpd_apcupsd_cgi_rw_content_t, httpd_munin_content_t, httpd_squid_content_t,
pki_tps_var_lib_t, pki_tps_var_run_t, httpd_awstats_script_exec_t,
httpd_smokeping_cgi_content_t, mailman_archive_t, httpd_cvs_content_t,
httpd_sys_content_t, logfile, public_content_rw_t, rpm_script_tmp_t,
mailman_data_t, security_t, httpd_munin_script_exec_t, var_lock_t, sysctl_t,
httpd_w3c_validator_script_exec_t, system_dbusd_var_lib_t,
system_dbusd_var_run_t, bin_t, cert_t, httpd_prewikka_rw_content_t,
httpd_user_script_exec_t, httpd_cobbler_content_t, squirrelmail_spool_t,
httpd_t, httpd_bugzilla_content_t, lib_t, mnt_t, tmp_t, usr_t, var_t,
httpd_apcupsd_cgi_script_exec_t, cobbler_var_lib_t, httpd_nagios_script_exec_t,
rpm_tmp_t, nagios_etc_t, nagios_log_t, var_run_t, sssd_public_t,
httpd_squid_script_exec_t, httpd_awstats_rw_content_t,
httpd_w3c_validator_rw_content_t, winbind_var_run_t, cluster_conf_t, autofs_t,
device_t, devpts_t, locale_t, likewise_var_lib_t, httpd_bugzilla_script_exec_t,
fonts_cache_t, etc_t, fonts_t, httpd_log_t, proc_t, sysfs_t, tmpfs_t,
httpd_awstats_content_t, var_lib_t, krb5_conf_t, httpd_user_rw_content_t,
httpd_config_t, httpd_nutups_cgi_content_t, sysctl_net_t, rpm_log_t,
httpd_cobbler_rw_content_t, httpd_prewikka_script_exec_t, calamaris_www_t,
httpd_munin_rw_content_t, var_spool_t, httpd_cache_t, httpd_tmpfs_t, udev_tbl_t,
httpd_tmp_t, httpd_sys_script_exec_t, iso9660_t, pki_tps_etc_rw_t,
smokeping_var_lib_t, httpd_git_script_exec_t, var_lib_t, var_run_t,
mysqld_etc_t, cvs_data_t, httpd_cvs_script_exec_t, configfile, pki_ra_etc_rw_t,
dbusd_etc_t, abrt_var_run_t, httpd_squirrelmail_t, httpd_bugzilla_ra_content_t,
httpd_bugzilla_rw_content_t, httpd_nutups_cgi_script_exec_t,
httpd_cvs_ra_content_t, httpd_cvs_rw_content_t, httpd_git_ra_content_t,
httpd_git_rw_content_t, httpd_nagios_content_t, httpd_sys_ra_content_t,
httpd_sys_rw_content_t, httpd_w3c_validator_content_t,
httpd_nagios_ra_content_t, httpd_nagios_rw_content_t,
httpd_nutups_cgi_ra_content_t, httpd_nutups_cgi_rw_content_t,
httpd_cobbler_script_exec_t, httpd_smokeping_cgi_script_exec_t,
httpd_git_content_t, httpd_user_content_t, root_t, nscd_var_run_t,
pcscd_var_run_t, httpd_squid_ra_content_t, httpd_squid_rw_content_t,
httpd_apcupsd_cgi_content_t, httpd_prewikka_content_t,
httpd_smokeping_cgi_ra_content_t, httpd_smokeping_cgi_rw_content_t,
httpd_apcupsd_cgi_ra_content_t, httpd_apcupsd_cgi_rw_content_t,
httpd_munin_content_t, httpd_squid_content_t, httpd_awstats_script_exec_t,
httpd_smokeping_cgi_content_t, httpd_cvs_content_t, httpd_sys_content_t,
httpd_munin_script_exec_t, httpd_w3c_validator_script_exec_t,
httpd_prewikka_ra_content_t, httpd_prewikka_rw_content_t,
httpd_user_script_exec_t, httpd_cobbler_content_t, httpd_bugzilla_content_t,
var_t, var_t, httpd_apcupsd_cgi_script_exec_t, httpd_nagios_script_exec_t,
httpd_squid_script_exec_t, httpd_awstats_ra_content_t,
httpd_awstats_rw_content_t, httpd_w3c_validator_ra_content_t,
httpd_w3c_validator_rw_content_t, httpd_bugzilla_script_exec_t,
httpd_awstats_content_t, httpd_user_ra_content_t, httpd_user_rw_content_t,
httpd_nutups_cgi_content_t, httpd_cobbler_ra_content_t,
httpd_cobbler_rw_content_t, httpd_prewikka_script_exec_t,
httpd_munin_ra_content_t, httpd_munin_rw_content_t, httpd_sys_script_exec_t,
httpd_git_script_exec_t, var_run_t, var_run_t, httpd_cvs_script_exec_t. You can
look at the httpd_selinux man page for additional information.

Additional Information:

Source Context unconfined_u:system_r:httpd_t:s0
Target Context system_ubject_r:dirsrv_config_t:s0
Target Objects /etc/dirsrv [ dir ]
Source httpd.worker
Source Path /usr/sbin/httpd.worker
Port <Unknown>
Host barfolomew.hra.local
Source RPM Packages httpd-2.2.15-1.fc13
Target RPM Packages 389-ds-base-1.2.6-0.8.rc3.fc13
Policy RPM selinux-policy-3.7.19-33.fc13
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Plugin Name httpd_bad_labels
Host Name barfolomew.hra.local
Platform Linux barfolomew.hra.local
2.6.33.6-147.fc13.x86_64 #1 SMP Tue Jul 6 22:32:17
UTC 2010 x86_64 x86_64
Alert Count 2
First Seen Thu 15 Jul 2010 11:09:00 AM CDT
Last Seen Thu 15 Jul 2010 11:09:00 AM CDT
Local ID 4120206e-3223-4145-90f9-a2e2129f42fa
Line Numbers

Raw Audit Messages

node=barfolomew.hra.local type=AVC msg=audit(1279210140.552:32139): avc: denied { search } for pid=12106 comm="httpd.worker" name="dirsrv" dev=dm-1 ino=1048465 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_ubject_r:dirsrv_config_t:s0 tclass=dir

node=barfolomew.hra.local type=SYSCALL msg=audit(1279210140.552:32139): arch=c000003e syscall=2 success=no exit=-13 a0=7f8458060dd0 a1=80000 a2=1b6 a3=7fffa028b610 items=0 ppid=12097 pid=12106 auid=2397 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="httpd.worker" exe="/usr/sbin/httpd.worker" subj=unconfined_u:system_r:httpd_t:s0 key=(null)


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 07-15-2010, 05:53 PM
Nathan Kinder
 
Default Announcing 389 Directory Server 1.2.6 Release Candidate 3

On 07/15/2010 09:12 AM, Aaron Hagopian wrote:
I upgraded my fedora 13 x86_64 machine to the RC3 using
the rpms in updates-testing and now I cannot start the admin server
with selinux enabled. *I am attaching the selinux message. *It does
start when I disable selinux.
What version of 389-admin are you running?



I'd also like to see the output of 'semodule -l | grep 389' from your
system.



-NGK







On Tue, Jul 6, 2010 at 2:38 PM, Rich
Megginson <rmeggins@redhat.com>
wrote:

The
389 team is pleased to announce the availability of Release

Candidate 3 of version 1.2.6. *This release has a few bug fixes.



***We need your help! *Please help us test this software.*** *It is a

release candidate, so it may have a few glitches, but it has been tested

for regressions and for new feature bugs. *The Fedora system

strongly encourages packages to be in Testing until verified and pushed

to Stable. *If we don't get any feedback while the packages are in

Testing, the packages will remain in limbo, or get pushed to Stable.



The more testing we get, the faster we can release these packages to

Stable. *See the Release Notes for information about how to provide

testing feedback (or just send an email to

389-users@lists.fedoraproject.org).



The packages that need testing are:

* 389-ds-base-1.2.6.rc3 - 389-ds-base



More information

* Release Notes - http://port389.org/wiki/Release_Notes

* Install_Guide - http://port389.org/wiki/Install_Guide

* Download - http://port389.org/wiki/Download



=== Bugs Fixed ===

This release contains a couple of bug fixes. *The complete list of bugs

fixed is found at the link below. *Note that bugs marked as MODIFIED

have been fixed but are still in testing.

* Tracking bug for 1.2.6 release -

https://bugzilla.redhat.com/showdependencytree.cgi?id=543590&hide_resolved=0

** *Bug 606920 - anonymous resource limit - nstimelimit - also applied

to "cn=directory manager"

** Bug 604453 - SASL Stress and Server crash: Program quits with the

assertion failure in PR_Poll

** Bug 605827 - In-place upgrade: upgrade dn format should not run in

setup-ds-admin.pl

** Bug 578296 - Attribute type entrydn needs to be added when subtree

rename switch is on

** Bug 609256 - Selinux: pwdhash fails if called via Admin Server CGI

** Bug 603942 - null deref in _ger_parse_control() for subjectdn



--

389 users mailing list

389-users@lists.fedoraproject.org

https://admin.fedoraproject.org/mailman/listinfo/389-users








--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users





--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 07-16-2010, 01:49 PM
Aaron Hagopian
 
Default Announcing 389 Directory Server 1.2.6 Release Candidate 3

As I was looking up the version number of admin I noticed that I had only updated 389-ds* and not 389* so the 389-admin* packages were mismatched. *Once I upgraded everything to what was in updates-testing no more selinux messages, sorry about the confusion.


Aaron

2010/7/15 Nathan Kinder <nkinder@redhat.com>








On 07/15/2010 09:12 AM, Aaron Hagopian wrote:
I upgraded my fedora 13 x86_64 machine to the RC3 using
the rpms in updates-testing and now I cannot start the admin server
with selinux enabled. *I am attaching the selinux message. *It does
start when I disable selinux.
What version of 389-admin are you running?



I'd also like to see the output of 'semodule -l | grep 389' from your
system.



-NGK







On Tue, Jul 6, 2010 at 2:38 PM, Rich
Megginson <rmeggins@redhat.com>
wrote:

The
389 team is pleased to announce the availability of Release

Candidate 3 of version 1.2.6. *This release has a few bug fixes.



***We need your help! *Please help us test this software.*** *It is a

release candidate, so it may have a few glitches, but it has been tested

for regressions and for new feature bugs. *The Fedora system

strongly encourages packages to be in Testing until verified and pushed

to Stable. *If we don't get any feedback while the packages are in

Testing, the packages will remain in limbo, or get pushed to Stable.



The more testing we get, the faster we can release these packages to

Stable. *See the Release Notes for information about how to provide

testing feedback (or just send an email to

389-users@lists.fedoraproject.org).



The packages that need testing are:

* 389-ds-base-1.2.6.rc3 - 389-ds-base



More information

* Release Notes - http://port389.org/wiki/Release_Notes

* Install_Guide - http://port389.org/wiki/Install_Guide

* Download - http://port389.org/wiki/Download



=== Bugs Fixed ===

This release contains a couple of bug fixes. *The complete list of bugs

fixed is found at the link below. *Note that bugs marked as MODIFIED

have been fixed but are still in testing.

* Tracking bug for 1.2.6 release -

https://bugzilla.redhat.com/showdependencytree.cgi?id=543590&hide_resolved=0

** *Bug 606920 - anonymous resource limit - nstimelimit - also applied

to "cn=directory manager"

** Bug 604453 - SASL Stress and Server crash: Program quits with the

assertion failure in PR_Poll

** Bug 605827 - In-place upgrade: upgrade dn format should not run in

setup-ds-admin.pl

** Bug 578296 - Attribute type entrydn needs to be added when subtree

rename switch is on

** Bug 609256 - Selinux: pwdhash fails if called via Admin Server CGI

** Bug 603942 - null deref in _ger_parse_control() for subjectdn



--

389 users mailing list

389-users@lists.fedoraproject.org

https://admin.fedoraproject.org/mailman/listinfo/389-users







--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users






--

389 users mailing list

389-users@lists.fedoraproject.org

https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 07-19-2010, 03:47 PM
Aaron Hagopian
 
Default Announcing 389 Directory Server 1.2.6 Release Candidate 3

Ok this time I think I have hit a legit issue with SELinux and 1.2.6 RC3. *On my workstation to sync up my ldap server with production I take a ldif dump from production and load it into my system with the ldif2db.pl script. *For versions 1.2.5 and previous that ldif file could be located anywhere that was readable to the "nobody" user. *Since upgrading, I try to use the same command and get denied because of SELinux. *


My real question here is what is an acceptable directory? *I thought for sure the*/var/lib/dirsrv/slapd-<instance>/ldif/ *directory would be acceptable but I get a "SELinux is preventing /usr/sbin/ns-slapd "read" access on ..." message no matter where I place the LDIF file.


Attached is the full SELinux error.
Thanks,
Aaron

On Fri, Jul 16, 2010 at 8:49 AM, Aaron Hagopian <airhead1@gmail.com> wrote:


As I was looking up the version number of admin I noticed that I had only updated 389-ds* and not 389* so the 389-admin* packages were mismatched. *Once I upgraded everything to what was in updates-testing no more selinux messages, sorry about the confusion.



Aaron

2010/7/15 Nathan Kinder <nkinder@redhat.com>









On 07/15/2010 09:12 AM, Aaron Hagopian wrote:
I upgraded my fedora 13 x86_64 machine to the RC3 using
the rpms in updates-testing and now I cannot start the admin server
with selinux enabled. *I am attaching the selinux message. *It does
start when I disable selinux.
What version of 389-admin are you running?



I'd also like to see the output of 'semodule -l | grep 389' from your
system.



-NGK







On Tue, Jul 6, 2010 at 2:38 PM, Rich
Megginson <rmeggins@redhat.com>
wrote:

The
389 team is pleased to announce the availability of Release

Candidate 3 of version 1.2.6. *This release has a few bug fixes.



***We need your help! *Please help us test this software.*** *It is a

release candidate, so it may have a few glitches, but it has been tested

for regressions and for new feature bugs. *The Fedora system

strongly encourages packages to be in Testing until verified and pushed

to Stable. *If we don't get any feedback while the packages are in

Testing, the packages will remain in limbo, or get pushed to Stable.



The more testing we get, the faster we can release these packages to

Stable. *See the Release Notes for information about how to provide

testing feedback (or just send an email to

389-users@lists.fedoraproject.org).



The packages that need testing are:

* 389-ds-base-1.2.6.rc3 - 389-ds-base



More information

* Release Notes - http://port389.org/wiki/Release_Notes

* Install_Guide - http://port389.org/wiki/Install_Guide

* Download - http://port389.org/wiki/Download



=== Bugs Fixed ===

This release contains a couple of bug fixes. *The complete list of bugs

fixed is found at the link below. *Note that bugs marked as MODIFIED

have been fixed but are still in testing.

* Tracking bug for 1.2.6 release -

https://bugzilla.redhat.com/showdependencytree.cgi?id=543590&hide_resolved=0

** *Bug 606920 - anonymous resource limit - nstimelimit - also applied

to "cn=directory manager"

** Bug 604453 - SASL Stress and Server crash: Program quits with the

assertion failure in PR_Poll

** Bug 605827 - In-place upgrade: upgrade dn format should not run in

setup-ds-admin.pl

** Bug 578296 - Attribute type entrydn needs to be added when subtree

rename switch is on

** Bug 609256 - Selinux: pwdhash fails if called via Admin Server CGI

** Bug 603942 - null deref in _ger_parse_control() for subjectdn



--

389 users mailing list

389-users@lists.fedoraproject.org

https://admin.fedoraproject.org/mailman/listinfo/389-users







--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users






--

389 users mailing list

389-users@lists.fedoraproject.org

https://admin.fedoraproject.org/mailman/listinfo/389-users





Summary:

SELinux is preventing /usr/sbin/ns-slapd "read" access on all-penny.ldif.

Detailed Description:

[SELinux is in permissive mode. This access was not denied.]

SELinux denied access requested by ns-slapd. It is not expected that this access
is required by ns-slapd and this access may signal an intrusion attempt. It is
also possible that the specific version or configuration of the application is
causing it to require additional access.

Allowing Access:

You can generate a local policy module to allow this access - see FAQ
(http://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Please file a bug
report.

Additional Information:

Source Context unconfined_u:system_r:dirsrv_t:s0
Target Context unconfined_ubject_r:var_t:s0
Target Objects all-penny.ldif [ file ]
Source ns-slapd
Source Path /usr/sbin/ns-slapd
Port <Unknown>
Host barfolomew.hra.local
Source RPM Packages 389-ds-base-1.2.6-0.8.rc3.fc13
Target RPM Packages
Policy RPM selinux-policy-3.7.19-33.fc13
Selinux Enabled True
Policy Type targeted
Enforcing Mode Permissive
Plugin Name catchall
Host Name barfolomew.hra.local
Platform Linux barfolomew.hra.local
2.6.33.6-147.fc13.x86_64 #1 SMP Tue Jul 6 22:32:17
UTC 2010 x86_64 x86_64
Alert Count 14
First Seen Mon 19 Jul 2010 10:17:57 AM CDT
Last Seen Mon 19 Jul 2010 10:43:17 AM CDT
Local ID c2f614a6-077e-4d38-b7a6-fd1161a959b0
Line Numbers

Raw Audit Messages

node=barfolomew.hra.local type=AVC msg=audit(1279554197.982:30320): avc: denied { read } for pid=9763 comm="ns-slapd" name="all-penny.ldif" dev=dm-3 ino=394927 scontext=unconfined_u:system_r:dirsrv_t:s0 tcontext=unconfined_ubject_r:var_t:s0 tclass=file

node=barfolomew.hra.local type=AVC msg=audit(1279554197.982:30320): avc: denied { open } for pid=9763 comm="ns-slapd" name="all-penny.ldif" dev=dm-3 ino=394927 scontext=unconfined_u:system_r:dirsrv_t:s0 tcontext=unconfined_ubject_r:var_t:s0 tclass=file

node=barfolomew.hra.local type=SYSCALL msg=audit(1279554197.982:30320): arch=c000003e syscall=2 success=yes exit=14 a0=7fd6ec34dcc0 a1=0 a2=0 a3=0 items=0 ppid=1 pid=9763 auid=2397 uid=99 gid=99 euid=99 suid=99 fsuid=99 egid=99 sgid=99 fsgid=99 tty=(none) ses=2 comm="ns-slapd" exe="/usr/sbin/ns-slapd" subj=unconfined_u:system_r:dirsrv_t:s0 key=(null)



--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 07-19-2010, 04:01 PM
Rich Megginson
 
Default Announcing 389 Directory Server 1.2.6 Release Candidate 3

Aaron Hagopian wrote:
> Ok this time I think I have hit a legit issue with SELinux and 1.2.6
> RC3. On my workstation to sync up my ldap server with production I
> take a ldif dump from production and load it into my system with the
> ldif2db.pl <http://ldif2db.pl> script. For versions 1.2.5 and
> previous that ldif file could be located anywhere that was readable to
> the "nobody" user. Since upgrading, I try to use the same command and
> get denied because of SELinux.
>
> My real question here is what is an acceptable directory? I thought
> for sure the /var/lib/dirsrv/slapd-<instance>/ldif/ directory would
> be acceptable but I get a "SELinux is preventing /usr/sbin/ns-slapd
> "read" access on ..." message no matter where I place the LDIF file.
>
> Attached is the full SELinux error.
Can you file a bug for this at
https://bugzilla.redhat.com/enter_bug.cgi?product=389 ? Thanks
>
> Thanks,
>
> Aaron
>
>
> On Fri, Jul 16, 2010 at 8:49 AM, Aaron Hagopian <airhead1@gmail.com
> <mailto:airhead1@gmail.com>> wrote:
>
> As I was looking up the version number of admin I noticed that I
> had only updated 389-ds* and not 389* so the 389-admin* packages
> were mismatched. Once I upgraded everything to what was in
> updates-testing no more selinux messages, sorry about the confusion.
>
> Aaron
>
> 2010/7/15 Nathan Kinder <nkinder@redhat.com
> <mailto:nkinder@redhat.com>>
>
> On 07/15/2010 09:12 AM, Aaron Hagopian wrote:
>> I upgraded my fedora 13 x86_64 machine to the RC3 using the
>> rpms in updates-testing and now I cannot start the admin
>> server with selinux enabled. I am attaching the selinux
>> message. It does start when I disable selinux.
> What version of 389-admin are you running?
>
> I'd also like to see the output of 'semodule -l | grep 389'
> from your system.
>
> -NGK
>
>>
>>
>> On Tue, Jul 6, 2010 at 2:38 PM, Rich Megginson
>> <rmeggins@redhat.com <mailto:rmeggins@redhat.com>> wrote:
>>
>> The 389 team is pleased to announce the availability of
>> Release
>> Candidate 3 of version 1.2.6. This release has a few bug
>> fixes.
>>
>> ***We need your help! Please help us test this
>> software.*** It is a
>> release candidate, so it may have a few glitches, but it
>> has been tested
>> for regressions and for new feature bugs. The Fedora system
>> strongly encourages packages to be in Testing until
>> verified and pushed
>> to Stable. If we don't get any feedback while the
>> packages are in
>> Testing, the packages will remain in limbo, or get pushed
>> to Stable.
>>
>> The more testing we get, the faster we can release these
>> packages to
>> Stable. See the Release Notes for information about how
>> to provide
>> testing feedback (or just send an email to
>> 389-users@lists.fedoraproject.org
>> <mailto:389-users@lists.fedoraproject.org>).
>>
>> The packages that need testing are:
>> * 389-ds-base-1.2.6.rc3 - 389-ds-base
>>
>> More information
>> * Release Notes - http://port389.org/wiki/Release_Notes
>> * Install_Guide - http://port389.org/wiki/Install_Guide
>> * Download - http://port389.org/wiki/Download
>>
>> === Bugs Fixed ===
>> This release contains a couple of bug fixes. The
>> complete list of bugs
>> fixed is found at the link below. Note that bugs marked
>> as MODIFIED
>> have been fixed but are still in testing.
>> * Tracking bug for 1.2.6 release -
>> https://bugzilla.redhat.com/showdependencytree.cgi?id=543590&hide_resolved=0
>> <https://bugzilla.redhat.com/showdependencytree.cgi?id=543590&hide_resolved=0>
>> ** Bug 606920 - anonymous resource limit - nstimelimit -
>> also applied
>> to "cn=directory manager"
>> ** Bug 604453 - SASL Stress and Server crash: Program
>> quits with the
>> assertion failure in PR_Poll
>> ** Bug 605827 - In-place upgrade: upgrade dn format
>> should not run in
>> setup-ds-admin.pl <http://setup-ds-admin.pl>
>> ** Bug 578296 - Attribute type entrydn needs to be added
>> when subtree
>> rename switch is on
>> ** Bug 609256 - Selinux: pwdhash fails if called via
>> Admin Server CGI
>> ** Bug 603942 - null deref in _ger_parse_control() for
>> subjectdn
>>
>> --
>> 389 users mailing list
>> 389-users@lists.fedoraproject.org
>> <mailto:389-users@lists.fedoraproject.org>
>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>
>>
>>
>> --
>> 389 users mailing list
>> 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>
>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> <mailto:389-users@lists.fedoraproject.org>
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
>
> ------------------------------------------------------------------------
>
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 07-19-2010, 06:25 PM
Nathan Kinder
 
Default Announcing 389 Directory Server 1.2.6 Release Candidate 3

On 07/19/2010 08:47 AM, Aaron Hagopian wrote:
Ok this time I think I have hit a legit issue with SELinux
and 1.2.6 RC3. *On my workstation to sync up my ldap server with
production I take a ldif dump from production and load it into my
system with the ldif2db.pl
script. *For versions 1.2.5 and previous that ldif file could be
located anywhere that was readable to the "nobody" user. *Since
upgrading, I try to use the same command and get denied because of
SELinux. *



My real question here is what is an acceptable directory? *I
thought for sure the*/var/lib/dirsrv/slapd-<instance>/ldif/
*directory would be acceptable but I get a "SELinux is preventing
/usr/sbin/ns-slapd "read" access on ..." message no matter where I
place the LDIF file.

How did you create the ldif file in
"/var/lib/dirsrv/slapd-<instance>/ldif/"?* Did you move the ldif
file there from elsewhere on your system?* That could explain why your
ldif file has an incorrect context of "var_t".



Try creating a new file in
"/var/lib/dirsrv/slapd-<instance>/ldif/" using 'touch', then run
'ls -lZ' to see what the SELinux context is on that new file.* It
should be "dirsrv_var_lib_t".



-NGK






Attached is the full SELinux error.



Thanks,


Aaron





On Fri, Jul 16, 2010 at 8:49 AM, Aaron
Hagopian <airhead1@gmail.com>
wrote:

As
I was looking up the version number of admin I noticed that I had only
updated 389-ds* and not 389* so the 389-admin* packages were
mismatched. *Once I upgraded everything to what was in updates-testing
no more selinux messages, sorry about the confusion.



Aaron



2010/7/15 Nathan Kinder <nkinder@redhat.com>





On 07/15/2010 09:12 AM, Aaron Hagopian wrote:
I upgraded my fedora 13 x86_64 machine to
the RC3 using
the rpms in updates-testing and now I cannot start the admin server
with selinux enabled. *I am attaching the selinux message. *It does
start when I disable selinux.

What version of 389-admin are you running?



I'd also like to see the output of 'semodule -l | grep 389' from your
system.



-NGK









On Tue, Jul 6, 2010 at 2:38 PM, Rich
Megginson <rmeggins@redhat.com>
wrote:

The
389
team is pleased to announce the availability of Release

Candidate 3 of version 1.2.6. *This release has a few bug fixes.



***We need your help! *Please help us test this software.*** *It is a

release candidate, so it may have a few glitches, but it has been tested

for regressions and for new feature bugs. *The Fedora system

strongly encourages packages to be in Testing until verified and pushed

to Stable. *If we don't get any feedback while the packages are in

Testing, the packages will remain in limbo, or get pushed to Stable.



The more testing we get, the faster we can release these packages to

Stable. *See the Release Notes for information about how to provide

testing feedback (or just send an email to

389-users@lists.fedoraproject.org).



The packages that need testing are:

* 389-ds-base-1.2.6.rc3 - 389-ds-base



More information

* Release Notes - http://port389.org/wiki/Release_Notes

* Install_Guide - http://port389.org/wiki/Install_Guide

* Download - http://port389.org/wiki/Download



=== Bugs Fixed ===

This release contains a couple of bug fixes. *The complete list of bugs

fixed is found at the link below. *Note that bugs marked as MODIFIED

have been fixed but are still in testing.

* Tracking bug for 1.2.6 release -

https://bugzilla.redhat.com/showdependencytree.cgi?id=543590&hide_resolved=0

** *Bug 606920 - anonymous resource limit - nstimelimit - also applied

to "cn=directory manager"

** Bug 604453 - SASL Stress and Server crash: Program quits with the

assertion failure in PR_Poll

** Bug 605827 - In-place upgrade: upgrade dn format should not run in

setup-ds-admin.pl

** Bug 578296 - Attribute type entrydn needs to be added when subtree

rename switch is on

** Bug 609256 - Selinux: pwdhash fails if called via Admin Server CGI

** Bug 603942 - null deref in _ger_parse_control() for subjectdn



--

389 users mailing list

389-users@lists.fedoraproject.org

https://admin.fedoraproject.org/mailman/listinfo/389-users







--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users








--

389 users mailing list

389-users@lists.fedoraproject.org

https://admin.fedoraproject.org/mailman/listinfo/389-users















--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users





--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 07-19-2010, 08:30 PM
Aaron Hagopian
 
Default Announcing 389 Directory Server 1.2.6 Release Candidate 3

I filed a bug per Rich:*https://bugzilla.redhat.com/show_bug.cgi?id=616206*

How did you create the ldif file in
"/var/lib/dirsrv/slapd-<instance>/ldif/"?* Did you move the ldif
file there from elsewhere on your system?* That could explain why your
ldif file has an incorrect context of "var_t".

Yes I moved the file there from another location. *I was just trying to see if there is some acceptable directory.

*


Try creating a new file in
"/var/lib/dirsrv/slapd-<instance>/ldif/" using 'touch', then run
'ls -lZ' to see what the SELinux context is on that new file.* It
should be "dirsrv_var_lib_t".

Yes creating a new file in that directory gets*dirsrv_var_lib_t. *I did get it in once I was able to get my file to have that SELinux attribute. *The ldif file was created on my production server which is running 1.2.5.


I can't say I know that much about SELinux but I imagine this may become a problem for people upgrading to 1.2.6 who want to start fresh? *Maybe can the db2ldif.pl utility add that SELinux attribute? *Although that seems like it would go against the point of SELinux if things can just add attributes as needed. *Does the file not have the attribute because it was created in 1.2.5 or was it because on my production machine, when I created the file (using db2ldif.pl), I saved it to a directory other than the SELinux one? *It looks like when I run the db2ldif.pl command on my 1.2.6 machine it does add some SELinux attributes.


I think the main reason I don't use the /var/lib/dirsrv/slapd-<instance>/ldif/ file for my backups in the first place is because by default the "nobody" user cannot write to that directory. *



*
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 07-19-2010, 08:39 PM
Rich Megginson
 
Default Announcing 389 Directory Server 1.2.6 Release Candidate 3

Aaron Hagopian wrote:
> I filed a bug per Rich: https://bugzilla.redhat.com/show_bug.cgi?id=616206
>
>
> How did you create the ldif file in
> "/var/lib/dirsrv/slapd-<instance>/ldif/"? Did you move the ldif
> file there from elsewhere on your system? That could explain why
> your ldif file has an incorrect context of "var_t".
>
>
> Yes I moved the file there from another location. I was just trying
> to see if there is some acceptable directory.
>
>
>
> Try creating a new file in
> "/var/lib/dirsrv/slapd-<instance>/ldif/" using 'touch', then run
> 'ls -lZ' to see what the SELinux context is on that new file. It
> should be "dirsrv_var_lib_t".
>
>
> Yes creating a new file in that directory gets dirsrv_var_lib_t. I
> did get it in once I was able to get my file to have that SELinux
> attribute. The ldif file was created on my production server which is
> running 1.2.5.
>
> I can't say I know that much about SELinux but I imagine this may
> become a problem for people upgrading to 1.2.6 who want to start
> fresh? Maybe can the db2ldif.pl <http://db2ldif.pl> utility add that
> SELinux attribute? Although that seems like it would go against the
> point of SELinux if things can just add attributes as needed. Does
> the file not have the attribute because it was created in 1.2.5 or was
> it because on my production machine, when I created the file (using
> db2ldif.pl <http://db2ldif.pl>), I saved it to a directory other than
> the SELinux one? It looks like when I run the db2ldif.pl
> <http://db2ldif.pl> command on my 1.2.6 machine it does add some
> SELinux attributes.
>
> I think the main reason I don't use the
> /var/lib/dirsrv/slapd-<instance>/ldif/ file for my backups in the
> first place is because by default the "nobody" user cannot write to
> that directory.
That's definitely a bug, possibly the real problem here.
>
>
>
> ------------------------------------------------------------------------
>
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 07-19-2010, 09:03 PM
Nathan Kinder
 
Default Announcing 389 Directory Server 1.2.6 Release Candidate 3

On 07/19/2010 01:30 PM, Aaron Hagopian wrote:


I filed a bug per Rich:*https://bugzilla.redhat.com/show_bug.cgi?id=616206
*

How did you create the ldif
file in
"/var/lib/dirsrv/slapd-<instance>/ldif/"?* Did you move the ldif
file there from elsewhere on your system?* That could explain why your
ldif file has an incorrect context of "var_t".






Yes I moved the file there from another location. *I was just
trying to see if there is some acceptable directory.


This explains it.* When you move a file, it's SELinux context is
preserved (as opposed to copying, which creates a new file with the
correct context for the target directory).



*



Try creating a new file in
"/var/lib/dirsrv/slapd-<instance>/ldif/" using 'touch', then run
'ls -lZ' to see what the SELinux context is on that new file.* It
should be "dirsrv_var_lib_t".






Yes creating a new file in that directory gets*dirsrv_var_lib_t.
*I did get it in once I was able to get my file to have that SELinux
attribute. *The ldif file was created on my production server which is
running 1.2.5.



I can't say I know that much about SELinux but I imagine this
may become a problem for people upgrading to 1.2.6 who want to start
fresh? *Maybe can the db2ldif.pl utility add that SELinux
attribute? *Although that seems like it would go against the point of
SELinux if things can just add attributes as needed. *Does the file not
have the attribute because it was created in 1.2.5 or was it because on
my production machine, when I created the file (using db2ldif.pl), I
saved it to a directory other than the SELinux one? *It looks like when
I run the db2ldif.pl
command on my 1.2.6 machine it does add some SELinux attributes.


This is a general problem for those new to SELinux.* A directory on the
file-system has a default SELinux context that will be used when a file
is created in it.* When you move a file from one location to another,
it's previous SELinux context is preserved.* This can cause issues like
what you've run into.* If you copy a file instead of moving it, the new
file will have the appropriate context as defined by the policy for the
target directory.






I think the main reason I don't use the
/var/lib/dirsrv/slapd-<instance>/ldif/ file for my backups in the
first place is because by default the "nobody" user cannot write to
that directory.*




The dirsrv SELinux is going make things like this more restrictive.*
It's one of those tradeoffs for being able to confine ns-slapd.



-NGK









*



--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users





--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 

Thread Tools




All times are GMT. The time now is 09:51 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org