Bug 487725 - modification of non-posix group to posix group doesn't catch magic number
modification of non-posix group to posix group doesn't catch magic number
Status: CLOSED CURRENTRELEASE
Product: 389
Classification: Community
Component: Server - DNA Plug-in (Show other bugs)
1.1.3
All Linux
low Severity medium
: ---
: ---
Assigned To: Nathan Kinder
Chandrasekar Kannan
:
Depends On:
Blocks: 249650 FDS1.2.0
  Show dependency treegraph
 
Reported: 2009-02-27 12:11 EST by Rob Crittenden
Modified: 2015-01-04 18:36 EST (History)
3 users (show)

See Also:
Fixed In Version: 8.1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-29 19:10:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description Rob Crittenden 2009-02-27 12:11:30 EST
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 13:59:52 EST
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 14:16:50 EST
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 16:30:42 EST
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 Galipeau 2009-04-07 16:02:55 EDT
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 19:10:55 EDT
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.