This file is indexed.

/etc/ldap/schema/dyngroup.schema is in slapd 2.4.45+dfsg-1ubuntu1.

This file is owned by root:root, with mode 0o644.

The actual contents of the file can be viewed below.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
# dyngroup.schema -- Dynamic Group schema
# $OpenLDAP$
## This work is part of OpenLDAP Software <http://www.openldap.org/>.
##
## Copyright 1998-2017 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' )

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 ) )