You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Emmanuel Lecharny (JIRA)" <ji...@apache.org> on 2008/05/06 00:17:55 UTC
[jira] Created: (DIRSERVER-1169) Access control don't apply to the
rootDSE
Access control don't apply to the rootDSE
-----------------------------------------
Key: DIRSERVER-1169
URL: https://issues.apache.org/jira/browse/DIRSERVER-1169
Project: Directory ApacheDS
Issue Type: Bug
Affects Versions: 1.5.2
Reporter: Emmanuel Lecharny
Fix For: 1.5.3
The getRootDSE operation ( a search operation done on a empty DN, with a BASE_OBJECT scope and a (ObjectClass=*) filter) is not checked against the ACIs, as the Authorization interceptor is not invoked.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (DIRSERVER-1169) Access control don't apply to the rootDSE
Posted by Alex Karasulu <ak...@apache.org>.
Ahh great points Howard! I did not at all think of these use cases and they
make perfect sense. Sounds though this is not an absolute must be something
we can take our time in implementing. Perhaps it's better to take more
time doing it right with partition nesting than finding a quick hack to make
this work right now.
Thanks again!
Alex
On Tue, May 6, 2008 at 9:40 AM, Howard Chu <hy...@symas.com> wrote:
> Alex Karasulu wrote:
>
> > No need to quote the RFC with me, I know that it can be subject to
> > access control - read my question. You know of situations when it is
> > actually set to anything but read-only by everyone?
> >
>
> There are cases where MacOS admins remove access to the
> supportedSASLMechanisms attribute, to prevent the clients from attempting
> SASL Binds. I don't recall all the reasons behind it, but suffice to say
> it's mostly just a bandaid over a buggy SASL implementation.
>
> You may also want to hide certain values from the
> supportedControls/supportedExtensions attributes, so that only particularly
> authenticated clients can see certain controls. (And furthermore you may
> want to prevent these controls/extensions from being used by various
> users...)
>
> --
> -- Howard Chu
> CTO, Symas Corp. http://www.symas.com
> Director, Highland Sun http://highlandsun.com/hyc/
> Chief Architect, OpenLDAP http://www.openldap.org/project/
>
Re: [jira] Created: (DIRSERVER-1169) Access control don't apply to
the rootDSE
Posted by Howard Chu <hy...@symas.com>.
Alex Karasulu wrote:
> No need to quote the RFC with me, I know that it can be subject to
> access control - read my question. You know of situations when it is
> actually set to anything but read-only by everyone?
There are cases where MacOS admins remove access to the
supportedSASLMechanisms attribute, to prevent the clients from attempting SASL
Binds. I don't recall all the reasons behind it, but suffice to say it's
mostly just a bandaid over a buggy SASL implementation.
You may also want to hide certain values from the
supportedControls/supportedExtensions attributes, so that only particularly
authenticated clients can see certain controls. (And furthermore you may want
to prevent these controls/extensions from being used by various users...)
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: [jira] Created: (DIRSERVER-1169) Access control don't apply to the rootDSE
Posted by Alex Karasulu <ak...@apache.org>.
We should be able to access control the RootDSE. The reason we cannot today
is because there's no way to make it an AP and have a subordinate subentry
for the ACIItem that will control access to it. My reason for asking about
the use cases was to try to weigh the need/criticality for this feature
verses the amount of work needed to do this without using a hack. The hack
would be to have a simple AA rooted at this RootDSE as the AP but nothing
below it. We could manage subentries as read only in memory objects for
this limited AA.
The right solution (non-hack) would be to enable nestable partitions, have a
root partition, and do away with the nexus. Then the whole tree is treated
in the same way with the same mechanism - no hacks.
This is why I wanted to know if the use case for anything other than read
only global exposure as we have it today is critical. If so then we can
prioritize this nested partition feature and have a root partition that can
hold AC subentries under the RootDSE to make it an AP. Looks like Howard
just posted some really good points - we need this feature but it's not
critical IMHO so it can wait until we get nested partitions in place.
Another reason why we should have a root partition with partition nesting so
we can get rid of the need to have both a system and a schema partition in
the server.
Alex
On Tue, May 6, 2008 at 9:23 AM, Emmanuel Lecharny <el...@apache.org>
wrote:
> Alex Karasulu wrote:
>
> > No need to quote the RFC with me, I know that it can be subject to
> > access control - read my question.
> >
> Sorry, I misunderstood your question, not intended to make you feel like
> you don't know the RFC.
>
> > You know of situations when it is actually set to anything but read-only
> > by everyone?
> >
> When you use HTTPd, you usually mask the version and name just for
> security reasons (if you know which version you are connected too, you can
> use the knowns security issues the specific version has to attack the
> server).
>
> I don't know if this is a strong enough use case anyway. Let say that this
> JIRA is pretty much a 'non conformance to the spec' JIRA.
>
> I can downgrade it to Improvement, instead of 'bug'.
>
> Not a big deal, really !
>
> >
> > Alex
> >
> > On Tue, May 6, 2008 at 1:04 AM, Emmanuel Lecharny <elecharny@apache.org<mailto:
> > elecharny@apache.org>> wrote:
> >
> > Alex Karasulu wrote:
> >
> > This is because the RootDSE is usually bare so applications
> > can perform discovery but some servers might want to protect
> > it. Know of any situation when the RootDSE could be hidden?
> >
> > RFC 4512 :
> >
> > 5.1. Server-Specific Data Requirements
> >
> > An LDAP server SHALL provide information about itself and other
> > information that is specific to each server. This is represented as
> > a group of attributes located in the root DSE, which is named with
> > the DN with zero RDNs (whose [RFC4514] representation is as the
> > zero-length string).
> >
> > These attributes are retrievable, _subject to access control_ and
> > other
> > restrictions, if a client performs a Search operation [RFC4511] with
> > an empty baseObject, scope of baseObject, the
> > filter"(objectClass=*)" [RFC4515], and the attributes field
> > listing the
> > names of the desired attributes.
> >
> >
> > -- --
> > cordialement, regards,
> > Emmanuel Lécharny
> > www.iktek.com <http://www.iktek.com>
> > directory.apache.org <http://directory.apache.org>
> >
> >
> >
> >
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>
Re: [jira] Created: (DIRSERVER-1169) Access control don't apply to
the rootDSE
Posted by Emmanuel Lecharny <el...@apache.org>.
Alex Karasulu wrote:
> No need to quote the RFC with me, I know that it can be subject to
> access control - read my question.
Sorry, I misunderstood your question, not intended to make you feel like
you don't know the RFC.
> You know of situations when it is actually set to anything but
> read-only by everyone?
When you use HTTPd, you usually mask the version and name just for
security reasons (if you know which version you are connected too, you
can use the knowns security issues the specific version has to attack
the server).
I don't know if this is a strong enough use case anyway. Let say that
this JIRA is pretty much a 'non conformance to the spec' JIRA.
I can downgrade it to Improvement, instead of 'bug'.
Not a big deal, really !
>
> Alex
>
> On Tue, May 6, 2008 at 1:04 AM, Emmanuel Lecharny
> <elecharny@apache.org <ma...@apache.org>> wrote:
>
> Alex Karasulu wrote:
>
> This is because the RootDSE is usually bare so applications
> can perform discovery but some servers might want to protect
> it. Know of any situation when the RootDSE could be hidden?
>
> RFC 4512 :
>
> 5.1. Server-Specific Data Requirements
>
> An LDAP server SHALL provide information about itself and other
> information that is specific to each server. This is represented as
> a group of attributes located in the root DSE, which is named with
> the DN with zero RDNs (whose [RFC4514] representation is as the
> zero-length string).
>
> These attributes are retrievable, _subject to access control_ and
> other
> restrictions, if a client performs a Search operation [RFC4511] with
> an empty baseObject, scope of baseObject, the
> filter"(objectClass=*)" [RFC4515], and the attributes field
> listing the
> names of the desired attributes.
>
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com <http://www.iktek.com>
> directory.apache.org <http://directory.apache.org>
>
>
>
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [jira] Created: (DIRSERVER-1169) Access control don't apply to the rootDSE
Posted by Alex Karasulu <ak...@apache.org>.
No need to quote the RFC with me, I know that it can be subject to access
control - read my question. You know of situations when it is actually set
to anything but read-only by everyone?
Alex
On Tue, May 6, 2008 at 1:04 AM, Emmanuel Lecharny <el...@apache.org>
wrote:
> Alex Karasulu wrote:
>
> > This is because the RootDSE is usually bare so applications can perform
> > discovery but some servers might want to protect it. Know of any situation
> > when the RootDSE could be hidden?
> >
> RFC 4512 :
>
> 5.1. Server-Specific Data Requirements
>
> An LDAP server SHALL provide information about itself and other
> information that is specific to each server. This is represented as
> a group of attributes located in the root DSE, which is named with
> the DN with zero RDNs (whose [RFC4514] representation is as the
> zero-length string).
>
> These attributes are retrievable, _subject to access control_ and other
> restrictions, if a client performs a Search operation [RFC4511] with
> an empty baseObject, scope of baseObject, the filter"(objectClass=*)"
> [RFC4515], and the attributes field listing the
> names of the desired attributes.
>
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>
Re: [jira] Created: (DIRSERVER-1169) Access control don't apply to
the rootDSE
Posted by Emmanuel Lecharny <el...@apache.org>.
Alex Karasulu wrote:
> This is because the RootDSE is usually bare so applications can
> perform discovery but some servers might want to protect it. Know of
> any situation when the RootDSE could be hidden?
RFC 4512 :
5.1. Server-Specific Data Requirements
An LDAP server SHALL provide information about itself and other
information that is specific to each server. This is represented as
a group of attributes located in the root DSE, which is named with
the DN with zero RDNs (whose [RFC4514] representation is as the
zero-length string).
These attributes are retrievable, _subject to access control_ and other
restrictions, if a client performs a Search operation [RFC4511] with
an empty baseObject, scope of baseObject, the filter"(objectClass=*)"
[RFC4515], and the attributes field listing the
names of the desired attributes.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [jira] Created: (DIRSERVER-1169) Access control don't apply to the rootDSE
Posted by Alex Karasulu <ak...@apache.org>.
This is because the RootDSE is usually bare so applications can perform
discovery but some servers might want to protect it. Know of any situation
when the RootDSE could be hidden?
BTW we cannot apply ACI to the RootDSE until we make it so we have a root
partition that can store subentry for the root AA with apex at the RootDSE.
Alex
On Mon, May 5, 2008 at 6:17 PM, Emmanuel Lecharny (JIRA) <ji...@apache.org>
wrote:
> Access control don't apply to the rootDSE
> -----------------------------------------
>
> Key: DIRSERVER-1169
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1169
> Project: Directory ApacheDS
> Issue Type: Bug
> Affects Versions: 1.5.2
> Reporter: Emmanuel Lecharny
> Fix For: 1.5.3
>
>
> The getRootDSE operation ( a search operation done on a empty DN, with a
> BASE_OBJECT scope and a (ObjectClass=*) filter) is not checked against the
> ACIs, as the Authorization interceptor is not invoked.
>
>
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
[jira] Updated: (DIRSERVER-1169) Access control don't apply to the
rootDSE
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-1169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Lecharny updated DIRSERVER-1169:
-----------------------------------------
Fix Version/s: 2.0.0-RC1
(was: 2.0.0)
Moved back to 2.0.0-RC1
> Access control don't apply to the rootDSE
> -----------------------------------------
>
> Key: DIRSERVER-1169
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1169
> Project: Directory ApacheDS
> Issue Type: Bug
> Affects Versions: 1.5.2
> Reporter: Emmanuel Lecharny
> Fix For: 2.0.0-RC1
>
>
> The getRootDSE operation ( a search operation done on a empty DN, with a BASE_OBJECT scope and a (ObjectClass=*) filter) is not checked against the ACIs, as the Authorization interceptor is not invoked.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRSERVER-1169) Access control don't apply to the
rootDSE
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-1169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Lecharny updated DIRSERVER-1169:
-----------------------------------------
Fix Version/s: (was: 1.5.3)
2.0.0
We can live with this until 2.0
> Access control don't apply to the rootDSE
> -----------------------------------------
>
> Key: DIRSERVER-1169
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1169
> Project: Directory ApacheDS
> Issue Type: Bug
> Affects Versions: 1.5.2
> Reporter: Emmanuel Lecharny
> Fix For: 2.0.0
>
>
> The getRootDSE operation ( a search operation done on a empty DN, with a BASE_OBJECT scope and a (ObjectClass=*) filter) is not checked against the ACIs, as the Authorization interceptor is not invoked.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.