Bug 487725

Summary: modification of non-posix group to posix group doesn't catch magic number
Product: [Retired] 389 Reporter: Rob Crittenden <rcritten>
Component: Server - DNA Plug-inAssignee: Nathan Kinder <nkinder>
Status: CLOSED CURRENTRELEASE QA Contact: Chandrasekar Kannan <ckannan>
Severity: medium Docs Contact:
Priority: low    
Version: 1.1.3CC: benl, jgalipea, rmeggins
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: 8.1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-04-29 23:10:55 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 249650, 493682    
Attachments:
Description Flags
CVS Diffs none

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