Coredump on ACLs for nonexistent Attributes. Is it a bug?
by Christian Marg
Hello,
I didn't find an ITS concerning what I encountered yesterday:
I had ACLs defined for undefined attributes (e.g. a schema file was
missing some entries) and slaptest etc. crashed with dumped core.
The message I got was:
slaptest in free(): error: junk pointer, too high to make sense
Abort (core dumped)
I'm using v 2.3.34 on FreeBSD 6.2-RELEASE-p3.
bye
Christian
--
Christian Marg mail : mailto:marg@rz.tu-clausthal.de
Dezernat 2 TU Clausthal web : http://www.tu-clausthal.de
D-38678 Clausthal-Zellerfeld fon : 05323/72-2107
Germany jabber: ifcma(a)jabber.tu-clausthal.de
15 years, 10 months
Re: Contribution: Active Directory Password Cache (ITS#5042)
by ando＠sys-net.it
ando(a)sys-net.it wrote:
> At this point, it sounds like that your contribution could be
> __entirely__ reworked into simply adding caching capabilities into the
> current {SASL} password scheme (implemented in servers/slapd/sasl.c),
> preserving the logics you're using right now. You'd probably need to
> define your own "cachedUserPassword" attribute to temporarily store the
> cached credentials, unless something like this:
>
> userPassword: {SASL}user
> userPassword: {<hash>}<hashed password>
>
> allows the {SASL} module to fetch the next value of the userPassowrd and
> treat it as the cached value. The rest would be adding some TTL mech,
> configurable via back-config, and that should be it.
>
> Yet another option would be to allow per-entry caching, by defining a
> new {CACHED-SASL} scheme. This way, one could fine-grain decide whose
> credentials can be cached and whose can't, letting the two cases share
> most of the code. I'd allow {SASL} to be cached as well, in case the
> administrator just wants to allow all {SASL} auths to be cached.
For this purpose, it might be necessary to change the API of password
scheme handling, so that it gets passed a pointer to the entire entry,
read-only locked, so that attributes like the "cachedPwd" and the
"cachedPwdTimestamp" can be fetched and used.
With respect to updating them, we might need to add some means to
schedule internal modifications to be performed as soon as the entry
lock is released. Thoughts?
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
15 years, 10 months
Re: Contribution: Active Directory Password Cache (ITS#5042)
by ando＠sys-net.it
s.hetze(a)linux-ag.de wrote:
> Renaming the variables is no problem. What would you say extpwc stands
> for?
EXT ernal P ass W ord C ache?
> I can imagine to call the module krb5pwc and head the README
> "Kerberos V/Active Directory Password Cache"
Right; but, this would limit yourself to Kerberos V; see my other
posting about rather delegating auth to SASL.
>> Well, that could be a parameter that is provided through the
>> configuration (caching TTL, optional negative caching TTL, and so). It
>> doesn't need to be stored in the entry, or in a subentry, since dynamic
>> configuration would allow to modify it run-time anyway.
>>
>
> If I understand it correct, you suggest to let the cached password
> expire after some configurable time. To achieve this, I would need to
> keep a timestamp when the password was cached.
> Is there any other way than to add an attribute holding this timestamp?
> ...
> Actually, I could make this feature depend on the {ad|krb5}pw-cache-mode=any
> and use the sambaPwdLastSet attribute.
Right; I think a specific operational attribute would be better.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
15 years, 10 months
Re: Contribution: Active Directory Password Cache (ITS#5042)
by s.hetze＠linux-ag.de
Hi Pierangelo,
On Tue, Aug 07, 2007 at 11:41:58AM +0200, Pierangelo Masarati wrote:
> s.hetze(a)linux-ag.de wrote:
>
> >>2) you could try to rework the overlay to avoid any specific reference
> >>to Active Directory, since your cache should apply to any remote system
> >>implementing Kerberos V. It could be abstracted even more, to act as a
> >>replacement of saslauthd, by allowing it to auth via LDAP, pam and more,
> >>not just Kerberos.
> >
> >Actually, the software was built and tested agains MIT and Heimdal
> >Kerberos V in the first place, so there is no dependency on AD
> >whatsoever. The reference to AD is more a marketing issue. I assume
> >more users looking for an AD password cache than for an Kerberos V
> >password cache. So I would perfer to keep it.
>
> I understand this, and I think it's just fine to advertise it like that,
> but in the code I'd prefer to avoid, for example, naming all variables
> after "ad" something. Perhaps s/adpwc/extpwc/ would be a little bit better?
Renaming the variables is no problem. What would you say extpwc stands
for? I can imagine to call the module krb5pwc and head the README
"Kerberos V/Active Directory Password Cache"
>
> >>3) you should add a (configurable) TTL, so that the cache could
> >>eventually be notified of an account lockout at the remote server's side.
> >
> >I tried to avoid introduction of new attributes for the module. Do you
> >have any suggestions how this TTL should be stored? Adding pwdPolicy
> >from ppolicy seems a bit like an overkill to me.
>
> Well, that could be a parameter that is provided through the
> configuration (caching TTL, optional negative caching TTL, and so). It
> doesn't need to be stored in the entry, or in a subentry, since dynamic
> configuration would allow to modify it run-time anyway.
>
If I understand it correct, you suggest to let the cached password
expire after some configurable time. To achieve this, I would need to
keep a timestamp when the password was cached.
Is there any other way than to add an attribute holding this timestamp?
...
Actually, I could make this feature depend on the {ad|krb5}pw-cache-mode=any
and use the sambaPwdLastSet attribute.
> >>4) you should add support for dynamic configuration, so that the module
> >>can fit into the new configuration paradigm for possible release with 2.4.
> >
> >I'll look into that.
>
> If you need help, please holler. However, I see that for such a simple
> (from a configuration point of view) module, looking into smbk5pwd
> should suffice.
Thanx for your offer, and I agree to look into the existing overlays
(again ;-)
That's the fun with free software!
Regards,
Sebastian
15 years, 10 months
Re: Contribution: Active Directory Password Cache (ITS#5042)
by ando＠sys-net.it
s.hetze(a)linux-ag.de wrote:
> I don't see the benefit of delegating the password cache mechanism to
> saslauthd or a possible replacement. Wouldn't I have to implement each
> possible password store anyway?
> If I understand it correct, the {SASL} userPassword mechanism delegates
> authentication to saslauthd.
> saslauthd can easily authenticate against Kerberos and AD and it is
> possible let it cache the password for its own authentication purposes.
> If I want the sambaNTPassword attribute to be available (to be able to
> run samba as a NT4 PDC independent of AD ) or if I want to have the
> password additionally cached as MIT Kerberos credential, I would need
> to implement both individually one way or another.
> So why not going the short way and let the overlay module do this?
The {SASL} userPassword delegates authentication to SASL; then, by
configuring SASL to use saslauthd, SASL delegates authentication to
saslauthd, but it can be delegated to anything else.
I think the point is: you should isolate what your piece of software is
originally contributing, and what it's "reinventing". The original
contribution, as far as I understand, is the capability to cache
athentication rather than always propagating it. This capability is not
currently present in OpenLDAP. What is already present is the SASL,
which is an abstraction layer for authentication; think of it as a
superset of Kerberos, which is the only authentication method you're
considering in your piece of software.
At this point, it sounds like that your contribution could be
__entirely__ reworked into simply adding caching capabilities into the
current {SASL} password scheme (implemented in servers/slapd/sasl.c),
preserving the logics you're using right now. You'd probably need to
define your own "cachedUserPassword" attribute to temporarily store the
cached credentials, unless something like this:
userPassword: {SASL}user
userPassword: {<hash>}<hashed password>
allows the {SASL} module to fetch the next value of the userPassowrd and
treat it as the cached value. The rest would be adding some TTL mech,
configurable via back-config, and that should be it.
Yet another option would be to allow per-entry caching, by defining a
new {CACHED-SASL} scheme. This way, one could fine-grain decide whose
credentials can be cached and whose can't, letting the two cases share
most of the code. I'd allow {SASL} to be cached as well, in case the
administrator just wants to allow all {SASL} auths to be cached.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
15 years, 10 months
Re: Contribution: Active Directory Password Cache (ITS#5042)
by s.hetze＠linux-ag.de
Hi Kurt,
On Mon, Aug 06, 2007 at 12:55:11PM -0700, Kurt Zeilenga wrote:
> >2) you could try to rework the overlay to avoid any specific reference
> >to Active Directory, since your cache should apply to any remote
> >system
> >implementing Kerberos V. It could be abstracted even more, to act
> >as a
> >replacement of saslauthd, by allowing it to auth via LDAP, pam and
> >more,
> >not just Kerberos.
>
> s/to act as a replacement/to defer external authentication to saslauthd
> or the like/
>
> In slapd(8), we deferred verification against external password
> stores to saslauthd
> via the {SASL} userPassword mechanism, thus avoiding needing to
> implement
> and support each possible external password store (such as a KDC).
> This module
> should likewise avoid supporting (some subset of) external passwords
> stores.
> saslauthd(8) can easily be extended (or replaced) to support additional
> password stores as needed. As provided in Cyrus SASL today, it
> supports both
> LDAP and Kerberos as external password stores.
>
I don't see the benefit of delegating the password cache mechanism to
saslauthd or a possible replacement. Wouldn't I have to implement each
possible password store anyway?
If I understand it correct, the {SASL} userPassword mechanism delegates
authentication to saslauthd.
saslauthd can easily authenticate against Kerberos and AD and it is
possible let it cache the password for its own authentication purposes.
If I want the sambaNTPassword attribute to be available (to be able to
run samba as a NT4 PDC independent of AD ) or if I want to have the
password additionally cached as MIT Kerberos credential, I would need
to implement both individually one way or another.
So why not going the short way and let the overlay module do this?
Regards,
Sebastian
15 years, 10 months
Re: Contribution: Active Directory Password Cache (ITS#5042)
by ando＠sys-net.it
s.hetze(a)linux-ag.de wrote:
>> 2) you could try to rework the overlay to avoid any specific reference
>> to Active Directory, since your cache should apply to any remote system
>> implementing Kerberos V. It could be abstracted even more, to act as a
>> replacement of saslauthd, by allowing it to auth via LDAP, pam and more,
>> not just Kerberos.
>
> Actually, the software was built and tested agains MIT and Heimdal
> Kerberos V in the first place, so there is no dependency on AD
> whatsoever. The reference to AD is more a marketing issue. I assume
> more users looking for an AD password cache than for an Kerberos V
> password cache. So I would perfer to keep it.
I understand this, and I think it's just fine to advertise it like that,
but in the code I'd prefer to avoid, for example, naming all variables
after "ad" something. Perhaps s/adpwc/extpwc/ would be a little bit better?
>> 3) you should add a (configurable) TTL, so that the cache could
>> eventually be notified of an account lockout at the remote server's side.
>
> I tried to avoid introduction of new attributes for the module. Do you
> have any suggestions how this TTL should be stored? Adding pwdPolicy
> from ppolicy seems a bit like an overkill to me.
Well, that could be a parameter that is provided through the
configuration (caching TTL, optional negative caching TTL, and so). It
doesn't need to be stored in the entry, or in a subentry, since dynamic
configuration would allow to modify it run-time anyway.
>> 4) you should add support for dynamic configuration, so that the module
>> can fit into the new configuration paradigm for possible release with 2.4.
>
> I'll look into that.
If you need help, please holler. However, I see that for such a simple
(from a configuration point of view) module, looking into smbk5pwd
should suffice.
>> 5) you should follow coding guidelines (indentation and so) as in most
>> of the code.
>
> I did not find any guidelines other than "Adapt your style to match that
> of the block, file, directory, or package that you are working in."
> Can you point me to a more detailed explanation of the required
> indentation?
There isn't actually, but looking into any "recent" piece of code would
suffice; things like: use tabs for indent, leave spaces in brackets and
so... not a big deal, though.
Cheers, p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
15 years, 10 months
Re: Contribution: Active Directory Password Cache (ITS#5042)
by s.hetze＠linux-ag.de
Hi Pierangelo,
thanx for your comments.
On Mon, Aug 06, 2007 at 09:32:27PM +0200, Pierangelo Masarati wrote:
> Sebastian,
>
> Thanks for the contribution.
>
> I have a few comments (also gathered from others):
>
> 1) you should provide patches against HEAD code; there has been some
> limited changes in the API related to overlay initialization and so.
No problem, I will look into that shortly.
>
> 2) you could try to rework the overlay to avoid any specific reference
> to Active Directory, since your cache should apply to any remote system
> implementing Kerberos V. It could be abstracted even more, to act as a
> replacement of saslauthd, by allowing it to auth via LDAP, pam and more,
> not just Kerberos.
Actually, the software was built and tested agains MIT and Heimdal
Kerberos V in the first place, so there is no dependency on AD
whatsoever. The reference to AD is more a marketing issue. I assume
more users looking for an AD password cache than for an Kerberos V
password cache. So I would perfer to keep it.
>
> 3) you should add a (configurable) TTL, so that the cache could
> eventually be notified of an account lockout at the remote server's side.
I tried to avoid introduction of new attributes for the module. Do you
have any suggestions how this TTL should be stored? Adding pwdPolicy
from ppolicy seems a bit like an overkill to me.
>
> 4) you should add support for dynamic configuration, so that the module
> can fit into the new configuration paradigm for possible release with 2.4.
I'll look into that.
>
> 5) you should follow coding guidelines (indentation and so) as in most
> of the code.
I did not find any guidelines other than "Adapt your style to match that
of the block, file, directory, or package that you are working in."
Can you point me to a more detailed explanation of the required
indentation?
Regards,
Sebastian
15 years, 10 months
(ITS#5077) syncrepl.add_cmp() infinite loop on swapped values
by donn＠u.washington.edu
Full_Name: Donn Cave
Version: 2.4.4
OS: Red Hat Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (128.95.135.150)
In "while" loop at 2656, I find old->a_vals are like [..., a, b, ...] and
new->a_vals are like [..., b, a, ...].
Matches are found at old [i] == new [k = j+1] and old [k = i+1] == new [j], but
this just shows that neither an add nor a delete is called for, and the loop end
is reached without having incremented i or j.
Actual attribute values I'm looking at right now in the debugger are
eduPersonAffiliation: old [ member, alum, employee, faculty ], new [ member,
alum, faculty, employee ]. I built the replica from a slapcat dump on the idle
master, started the slapd syncrepl client and applied a lot of normal
modifications to the master, until it hit the infinite loop. It has been a
recurrent problem.
15 years, 10 months
Re: Contribution: Active Directory Password Cache (ITS#5042)
by kurt＠OpenLDAP.org
On Aug 6, 2007, at 7:31 PM, ando(a)sys-net.it wrote:
> Sebastian,
>
> Thanks for the contribution.
>
> I have a few comments (also gathered from others):
>
> 1) you should provide patches against HEAD code; there has been some
> limited changes in the API related to overlay initialization and so.
>
> 2) you could try to rework the overlay to avoid any specific reference
> to Active Directory, since your cache should apply to any remote
> system
> implementing Kerberos V. It could be abstracted even more, to act
> as a
> replacement of saslauthd, by allowing it to auth via LDAP, pam and
> more,
> not just Kerberos.
s/to act as a replacement/to defer external authentication to saslauthd
or the like/
In slapd(8), we deferred verification against external password
stores to saslauthd
via the {SASL} userPassword mechanism, thus avoiding needing to
implement
and support each possible external password store (such as a KDC).
This module
should likewise avoid supporting (some subset of) external passwords
stores.
saslauthd(8) can easily be extended (or replaced) to support additional
password stores as needed. As provided in Cyrus SASL today, it
supports both
LDAP and Kerberos as external password stores.
>
> 3) you should add a (configurable) TTL, so that the cache could
> eventually be notified of an account lockout at the remote server's
> side.
>
> 4) you should add support for dynamic configuration, so that the
> module
> can fit into the new configuration paradigm for possible release
> with 2.4.
>
> 5) you should follow coding guidelines (indentation and so) as in most
> of the code.
>
> p.
15 years, 10 months
