https://bugs.openldap.org/show_bug.cgi?id=6198
--- Comment #6 from Ondřej Kuzník <ondra(a)mistotebe.net> ---
A few open questions I can't resolve yet:
- Do we rely on OID macros from schema or let slap_control/load_extop2 register
it? The suggestions above tend to prefer OID macros but they have to be defined
in the schema (there's only one) and they're currently case-sensitive
For controls:
- Do we want to be able to use ACLs to turn non-critical controls to ignored?
- Do we want to be able to use ACLs to refuse control combinations?
- Apart from the 'to' clause, do we want it allowed in the 'by' clause as well
(when would it be useful? There's control combinations, anything else?)
I'll start with "no" to all 3 of the above for now.
As for combination with other specifiers (especially for exops), ACL checks are
issued with the operation and an entry right now, they do make sense in that
scope so password modify/DDS refresh should be in the clear. Other extops are
more of a problem:
- whoami: technically there is a DN but it doesn't have to correspond to an
entry
- verify credentials: tricky, since it's processed as a bind
- cancel: abandon can't be restricted, so probably the same
- turn: no idea
- ChainedRequest: even less of one
Probably happy for those to be impossible to restrict in this way, at least for
now.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10257
Issue ID: 10257
Summary: Documentation assessment
Product: OpenLDAP
Version: 2.6.8
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
Created attachment 1031
--> https://bugs.openldap.org/attachment.cgi?id=1031&action=edit
Admin guide assessment
Last month I commissioned a tech writer to review the current 2.6 Admin Guide
to see what needs to be worked on before the 2.7 release. I'm attaching the
report here so we can reference it. Should have distributed it sooner but Life
got in the way.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10256
Issue ID: 10256
Summary: Custom attribute disappears after slapd restart
Product: OpenLDAP
Version: 2.4.57
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: heinrich.blatt(a)googlemail.com
Target Milestone: ---
Hi,
i want to use a custom attribute in my schema. I use that ldif:
dn: cn=schema,cn=config
changetype: modify
add: olcAttributeTypes
olcAttributeTypes: ( 1.2.840.113556.1.4.7000 NAME 'rfidtoken' DESC 'RFID Token'
EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
This i inject via ldapmodify. For the session it works, but after restarting
slapd the attribute disappears. If i add it again via ldapmodify it is there
for the session again. My /etc/ldap/slapd.d/cn=config/cn=schema.ldif contains
the change.
This seems related to #9066, however the documentation indicates that i can
make the changes via ldapmodify persistent.
What is the right approach there? What i can do to persist the change?
Thanks in advance for support
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8905
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|bugs(a)openldap.org |gnoe(a)symas.com
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=7982
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|bugs(a)openldap.org |ondra(a)mistotebe.net
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9920
Issue ID: 9920
Summary: MDB_PAGE_FULL with master3 (encryption) because there
is no room for the authentication data (MAC)
Product: LMDB
Version: unspecified
Hardware: x86_64
OS: Mac OS
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: info(a)parlepeuple.fr
Target Milestone: ---
Created attachment 915
--> https://bugs.openldap.org/attachment.cgi?id=915&action=edit
proposed patch
Hello,
on master3, using the encryption at rest feature,
I am testing as follow:
- on a new named database, i set the encryption function with
mdb_env_set_encrypt(env, encfunc, &enckey, 32)
- note that I chose to have a size parameter (The size of authentication data
in bytes, if any. Set this to zero for unauthenticated encryption mechanisms.)
of 32 bytes.
- I add 2 entries on the DB, trying to saturate the first page. I chose to add
a key of 33 Bytes and a value of 1977 Bytes, so the size of each node is 2010
Bytes (obviously the 2 keys are different).
- This passes and the DB has just one leaf_pages, no overflow_pages, no
branch_pages, an a depth of 1.
- If I add one byte to the values I insert (starting again from a blank DB),
then , instead of seeing 2 overflow_pages, I get an error : MDB_PAGE_FULL.
- this clearly should not have happened.
- Here is some tracing :
add to leaf page 2 index 0, data size 48 key size 7 [74657374646200]
add to leaf page 3 index 0, data size 1978 key size 33
[000000000000000000000000000000000000000000000000000000000000000000]
add to branch page 5 index 0, data size 0 key size 0 [null]
add to branch page 5 index 1, data size 0 key size 33
[000000000000000000000000000000000000000000000000000000000000000000]
add to leaf page 4 index 0, data size 1978 key size 33
[000000000000000000000000000000000000000000000000000000000000000000]
add to leaf page 4 index 1, data size 1978 key size 33
[020202020202020202020202020202020202020202020202020202020202020202]
not enough room in page 4, got 1 ptrs
upper-lower = 2020 - 2 = 2016
node size = 2020
Looking at the code, I understand that there is a problem at line 9005 :
} else if (node_size + data->mv_size > mc->mc_txn->mt_env->me_nodemax) {
where me_nodemax is incorrect, as it is not taking into account that some bytes
will be needed for the MAC authentication code, which size is in
env->me_esumsize.
me_nodemax is calculated at line 5349:
env->me_nodemax = (((env->me_psize - PAGEHDRSZ ) / MDB_MINKEYS) & -2)
- sizeof(indx_t);
So I substract me_esumsize with a "- env->me_esumsize" here:
env->me_nodemax = (((env->me_psize - PAGEHDRSZ - env->me_esumsize) /
MDB_MINKEYS) & -2)
- sizeof(indx_t);
I also substract it from me_maxfree_1pg in the line above, and in pmax in line
10435.
I do not know if my patch is correct, but it solves the issue.
Maybe there are other places in the code where the me_esumsize should be
substracted from the available size. By example, when calculating the number of
overflow pages in OVPAGES, it does not take into account me_esumsize, but I
think it is ok, because there is only one MAC for the entire set of OV pages,
and there is room for it in the first OV page.
See the attached proposed patch.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9367
Issue ID: 9367
Summary: back-mdb: encryption support
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Need to add encryption support to the back-mdb backend, depends on issue#9364
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9225
Bug ID: 9225
Summary: back-mdb: Add support for PREPARE/2-phase commit
Product: OpenLDAP
Version: 2.4.50
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Add support for PREPARE/2-phase commit in back-mdb
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9398
Issue ID: 9398
Summary: Stale accesslog cookie due to unclean shutdown
Product: OpenLDAP
Version: 2.4.56
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
If slapd terminates uncleanly, a checkpoint will be lost on the accesslog db.
Depending on the syncprov overlay checkpoint settings (usually no checkpointing
is enabled on the accesslog db) this can cause the system to refuse engage in
replication at startup.
--
You are receiving this mail because:
You are on the CC list for the issue.