Bug 487725 - modification of non-posix group to posix group doesn't catch magic number
Summary: modification of non-posix group to posix group doesn't catch magic number
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: 389
Classification: Retired
Component: Server - DNA Plug-in
Version: 1.1.3
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Nathan Kinder
QA Contact: Chandrasekar Kannan
URL:
Whiteboard:
Depends On:
Blocks: 249650 FDS1.2.0
TreeView+ depends on / blocked
 
Reported: 2009-02-27 17:11 UTC by Rob Crittenden
Modified: 2015-01-04 23:36 UTC (History)
3 users (show)

Fixed In Version: 8.1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-04-29 23:10:55 UTC
Embargoed:


Attachments (Terms of Use)
CVS Diffs (4.75 KB, patch)
2009-02-27 18:59 UTC, Nathan Kinder
no flags Details | Diff

Description Rob Crittenden 2009-02-27 17:11:30 UTC
Description of problem:

If I create a group that is non-posix and want to upgrade it to be a posix group by adding the posixGroup objectclass and setting gidnumber to the DNA magic value, the entry is updated but the magic value doesn't cause DNA to generate a new value. gidnumber is stored as the magic value.

Version-Release number of selected component (if applicable):

fedora-ds-base-1.1.3-3.fc9.i386

Steps to Reproduce:

The DNA config is:

dn: cn=Groups,cn=Posix,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=
 config
objectClass: top
objectClass: extensibleObject
cn: Groups
dnatype: gidNumber
dnainterval: 1
dnamaxvalue: 1000000000
dnamagicregen: 999
dnafilter: (objectclass=posixGroup)
dnascope: dc=example,dc=com
dnanextvalue: 1302

My group entry starts with:

dn: cn=new8,cn=groups,cn=accounts,dc=example,dc=com
objectClass: top
objectClass: groupofnames
objectClass: ipaUserGroup
objectClass: nestedGroup
cn: new8
description: new8

The special objectclasses are:

objectClasses:
  ( 2.16.840.1.113730.3.8.4.3 NAME 'nestedGroup'
    DESC 'Group that supports nesting'
    SUP groupOfNames STRUCTURAL
    MAY memberOf
    X-ORIGIN 'IPA v2' )

    X-ORIGIN 'IPA v2' )
objectClasses:
  ( 2.16.840.1.113730.3.8.4.4 NAME 'ipaUserGroup'
    DESC 'IPA user group object class'
    SUP nestedGroup STRUCTURAL
    X-ORIGIN 'IPA v2' )

Tested with this ldapmodify:

dn: cn=new8,cn=groups,cn=accounts,dc=example,dc=com
changetype: modify
add: objectclass
objectclass: posixgroup
-
add: gidnumber
gidnumber: 999

The modification works but the value of gidnumber remains 999 instead of generating a new one.

From what I can tell the filter isn't matching because posixGroup hasn't really been added to the entry yet.

Comment 1 Nathan Kinder 2009-02-27 18:59:52 UTC
Created attachment 333521 [details]
CVS Diffs

This patch handles modify operations that bring entries into or out of scope of a managed range.  If you bring an entry into scope (say by adding the appropriate objectclass), this will assign a value from the range if the magic value or no value is supplied for the managed type.

Comment 2 Rob Crittenden 2009-02-27 19:16:50 UTC
This fixes it for the ldapmodify test case and I successfully tested it with python-ldap as well.

Comment 3 Nathan Kinder 2009-02-27 21:30:42 UTC
Checked into ldapserver (HEAD).  Thanks to Rich for his review, and to Rob for his testing!

Checking in ldap/servers/plugins/dna/dna.c;
/cvs/dirsec/ldapserver/ldap/servers/plugins/dna/dna.c,v  <--  dna.c
new revision: 1.18; previous revision: 1.17
done

Comment 4 Jenny Severance 2009-04-07 20:02:55 UTC
fix verified RHEL 4 DS 8.1

Add regular user modify and then add Posix Account objectclass with no uid assigned
Add regular user modify and add Posix Account objectclass with magic uid assigned
Add regular group modify and then add Posix Group objectclass with no gid assigned
Add regular group modify and then add Posix Group objectclass with magic gid assigned

all DNA assigned managed numbers were assigned correctly and dna next values iterated correctly.

Working on adding these to DNA automated acceptance tests.

Comment 5 Chandrasekar Kannan 2009-04-29 23:10:55 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2009-0455.html


Note You need to log in before you can comment on or make changes to this bug.