>The way the code is currently written is, if there is a duplicate:
>- check if the "new" group has the same SID, uniqueID or original DN
> as the "old" one
> - yes, same: this is a rename, allow
> - no, different: this is a duplicate, error
I'm not clear on the start of this
On Mon, 2018-09-24 at 19:59 +0200, Jakub Hrozek wrote:
> On Mon, Sep 24, 2018 at 10:22:35AM -0400, Simo Sorce wrote:
> > > btw it’s a good question to ask why isn’t the check done on saving
> > > the group. I thought it was and I see code that checks for ID
> > > uniqueness and even a test..
> >
On Mon, Sep 24, 2018 at 04:40:34PM +0200, Michael Ströder wrote:
> On 9/24/18 4:12 PM, Beale (US), Gareth wrote:
> >> I’m not so sure it would be a good idea to support this, honestly.
> >
> > Well that rather depends on what you mean by "this". I was reporting
> > a problem that seemed an
On Mon, Sep 24, 2018 at 10:22:35AM -0400, Simo Sorce wrote:
> > btw it’s a good question to ask why isn’t the check done on saving
> > the group. I thought it was and I see code that checks for ID
> > uniqueness and even a test..
>
> In current code, saving would override data as if the group was
It's a good discussion, and I don't necessarily disagree with your thoughts on
groups with the same GID, despite the nss_ldap implementation. I'd agree that
any change in behavior should have an option to revert to previous but that it
shouldn't be the default.
However, is the issue with
On Mon, 2018-09-24 at 16:44 +0200, Michael Ströder wrote:
> On 9/24/18 4:22 PM, Simo Sorce wrote:
> > For groups I would expect us to merge memberships in rfc2307 mode,
>
> If you really want to implement such merging then please disable
> it by default. So that it must be explicitly enabled
On 9/24/18 4:22 PM, Simo Sorce wrote:
> For groups I would expect us to merge memberships in rfc2307 mode,
If you really want to implement such merging then please disable
it by default. So that it must be explicitly enabled after careful
consideration.
Ciao, Michael.
smime.p7s
Description:
On 9/24/18 4:12 PM, Beale (US), Gareth wrote:
>> I’m not so sure it would be a good idea to support this, honestly.
>
> Well that rather depends on what you mean by "this". I was reporting
> a problem that seemed an inconsistency to me. Either multiple groups
> with the same GID are supported, or
On Mon, 2018-09-24 at 11:38 +0200, Jakub Hrozek wrote:
> > On 21 Sep 2018, at 20:36, gfb...@yahoo.com wrote:
> >
> > For our case, say we have a set of groups abcd..1, abcd..2 etc, all
> > with the same GID. I would expect the first lookup (e.g. abcd..1)
> > to put an entry in the cache. If there
>I’m not so sure it would be a good idea to support this, honestly.
Well that rather depends on what you mean by "this". I was reporting a problem
that seemed an inconsistency to me. Either multiple groups with the same GID
are supported, or they aren't. The current implementation is
> On 21 Sep 2018, at 20:36, gfb...@yahoo.com wrote:
>
> For our case, say we have a set of groups abcd..1, abcd..2 etc, all with the
> same GID. I would expect the first lookup (e.g. abcd..1) to put an entry in
> the cache. If there is then a lookup by GID, (getent group ) it would
> return
11 matches
Mail list logo
