Adding upstream version 2.5.13+dfsg.upstream/2.5.13+dfsgupstream

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 98 insertions, 0 deletions

diff --git a/servers/slapd/schema/dyngroup.schema b/servers/slapd/schema/dyngroup.schema
new file mode 100644
index 0000000..f756c33
--- /dev/null
+++ b/servers/slapd/schema/dyngroup.schema
@@ -0,0 +1,98 @@
+# dyngroup.schema -- Dynamic Group schema
+# $OpenLDAP$
+## This work is part of OpenLDAP Software <http://www.openldap.org/>.
+##
+## Copyright 1998-2022 The OpenLDAP Foundation.
+## All rights reserved.
+##
+## Redistribution and use in source and binary forms, with or without
+## modification, are permitted only as authorized by the OpenLDAP
+## Public License.
+##
+## A copy of this license is available in the file LICENSE in the
+## top-level directory of the distribution or, alternatively, at
+## <http://www.OpenLDAP.org/license.html>.
+#
+# Dynamic Group schema (experimental), as defined by Netscape.  See
+# http://www.redhat.com/docs/manuals/ent-server/pdf/esadmin611.pdf
+# page 70 for details on how these groups were used.
+#
+# A description of the objectclass definition is available here:
+# http://www.redhat.com/docs/manuals/dir-server/schema/7.1/oc_dir.html#1303745
+#
+# depends upon:
+#	core.schema
+#
+# These definitions are considered experimental due to the lack of
+# a formal specification (e.g., RFC).
+#
+# NOT RECOMMENDED FOR PRODUCTION USE!  USE WITH CAUTION!
+#
+# The Netscape documentation describes this as an auxiliary objectclass
+# but their implementations have always defined it as a structural class.
+# The sloppiness here is because Netscape-derived servers don't actually
+# implement the X.500 data model, and they don't honor the distinction
+# between structural and auxiliary classes. This fact is noted here:
+# http://forum.java.sun.com/thread.jspa?threadID=5016864&messageID=9034636
+#
+# In accordance with other existing implementations, we define it as a
+# structural class.
+#
+# Our definition of memberURL also does not match theirs but again
+# their published definition and what works in practice do not agree.
+# In other words, the Netscape definitions are broken and interoperability
+# is not guaranteed.
+#
+# Also see the new DynGroup proposed spec at
+# http://tools.ietf.org/html/draft-haripriya-dynamicgroup-02
+
+objectIdentifier NetscapeRoot 2.16.840.1.113730
+
+objectIdentifier NetscapeLDAP NetscapeRoot:3
+objectIdentifier NetscapeLDAPattributeType NetscapeLDAP:1
+objectIdentifier NetscapeLDAPobjectClass NetscapeLDAP:2
+
+objectIdentifier OpenLDAPExp11	1.3.6.1.4.1.4203.666.11
+objectIdentifier DynGroupBase	OpenLDAPExp11:8
+objectIdentifier DynGroupAttr	DynGroupBase:1
+objectIdentifier DynGroupOC	DynGroupBase:2
+
+attributetype ( NetscapeLDAPattributeType:198
+	NAME 'memberURL'
+	DESC 'Identifies an URL associated with each member of a group. Any type of labeled URL can be used.'
+	SUP labeledURI )
+
+attributetype ( DynGroupAttr:1
+	NAME 'dgIdentity'
+	DESC 'Identity to use when processing the memberURL'
+	SUP distinguishedName SINGLE-VALUE )
+
+attributeType ( DynGroupAttr:2
+	NAME 'dgAuthz'
+	DESC 'Optional authorization rules that determine who is allowed to assume the dgIdentity'
+	EQUALITY authzMatch
+	SYNTAX 1.3.6.1.4.1.4203.666.2.7
+	X-ORDERED 'VALUES' )
+
+# Just for testing. The actual memberOf is an operational attribute
+attributeType ( DynGroupAttr:3
+	NAME 'dgMemberOf'
+	DESC 'Group that the entry belongs to'
+	SYNTAX '1.3.6.1.4.1.1466.115.121.1.12'
+	EQUALITY distinguishedNameMatch )
+
+objectClass ( NetscapeLDAPobjectClass:33
+	NAME 'groupOfURLs'
+	SUP top STRUCTURAL
+	MUST cn
+	MAY ( memberURL $ businessCategory $ description $ o $ ou $
+		owner $ seeAlso ) )
+
+# The Haripriya dyngroup schema still needs a lot of work.
+# We're just adding support for the dgIdentity attribute for now...
+objectClass ( DynGroupOC:1
+	NAME 'dgIdentityAux'
+	SUP top AUXILIARY
+	MAY ( dgIdentity $ dgAuthz ) )
+
+