Bug 144493 - Handling of KRB5_KTNAME environment variable
Summary: Handling of KRB5_KTNAME environment variable
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: openldap
Version: 3
Hardware: All
OS: Linux
medium
low
Target Milestone: ---
Assignee: Jay Fenlason
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-01-07 18:13 UTC by Aleksandar Milivojevic
Modified: 2014-08-31 23:27 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2006-11-29 15:20:45 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
/etc/init.d/ldap patch to handle KRB5_KTNAME (600 bytes, patch)
2005-01-07 18:14 UTC, Aleksandar Milivojevic
no flags Details | Diff

Description Aleksandar Milivojevic 2005-01-07 18:13:08 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041111 Firefox/1.0

Description of problem:
Currently, there is only one way to specify alternative Kerberos
keytab file when starting slapd, and that is using KRB5_KTNAME
environment variable.  Use of this variable is needed, since keytab
file shouldn't be readable by ordinary users, and system-wide keytab
file is owned by user root and readable only by root (hence need for
separate keytab file, group-readable by ldap group that contains key
for ldap/hostname@REALM service principal).

It would be nice if /etc/init.d/ldap would check if KRB5_KTNAME is
defined and non-empty (for example in /etc/sysconfig/ldap) and export
it before starting slapd.

Workaround (that I'm currently using) is placing export statement
directly into /etc/sysconfing/ldap:

KRB5_KTNAME=....
export KRB5_KTNAME


Version-Release number of selected component (if applicable):
openldap-servers-2.2.13-2

How reproducible:
Always

Steps to Reproduce:
1. Attempt using GSSAPI with slapd/ldapsearch


Additional info:

Comment 1 Aleksandar Milivojevic 2005-01-07 18:14:15 UTC
Created attachment 109482 [details]
/etc/init.d/ldap patch to handle KRB5_KTNAME

Comment 2 Rudi Chiarito 2005-05-21 17:43:12 UTC
Was this recently fixed?

https://www.redhat.com/archives/fedora-cvs-commits/2005-April/msg01356.html

Just helping Fedora's and Nalin's bug lists shrink.

Comment 3 Aleksandar Milivojevic 2005-05-22 03:07:00 UTC
Yup, looking in the current sources from development tree, it seems to be fixed
and handled in much more elaborate way than in my simple patch.  I guess this
could be closed as RAWHIDE.

Comment 4 Matthew Miller 2006-07-10 23:03:55 UTC
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!



Note You need to log in before you can comment on or make changes to this bug.