Bug#282184: [Pkg-shadow-devel] Bug#282184: More information needed for this bug

[Vincent Lefevre]

On 2005-09-28 18:16:21 +0200, Christian Perrier wrote:
> All advices I've gathered up to now around me tend to mention that
> having same names for groups with different GIDs in different
> databases is a completely strange idea

Here it was the *same* GID. This is a good idea
  * to avoid clashes with the NIS database by making some kind of
copy of the NIS database locally,
  * to avoid some packages from stealing GIDs normally reserved for
the NIS database (the slocate package created a group with GID
1001).

But I think that having different GIDs may be useful in some cases,
where the sysadmins don't support Debian: Debian packages may want
to create groups whose name already exist in the NIS database.
Unfortunately there are no namespaces to avoid group name clashes.

> which certainly low level tools shouldn't support.

Then the documentation should be fixed.

> The best motivated advice I had up to now as "hey, if you really want
> to do this, why not just use vi on /etc/group|/etc/gshadow?"

What if some script wants to create a group locally?

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / SPACES project at LORIA


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#282184: [Pkg-shadow-devel] Bug#282184: More information needed for this bug

[Christian Perrier]

tags 282184 wontfix
thanks

> I don't think so. getent may use remote databases, whereas groupadd
> is purely local (according to the man page).
> 
> And some packages use it to create local groups.


All advices I've gathered up to now around me tend to mention that
having same names for groups with different GIDs in different
databases is a completely strange idea which certainly low level tools
shouldn't support.

The best motivated advice I had up to now as "hey, if you really want
to do this, why not just use vi on /etc/group|/etc/gshadow?"

As I completely agree with this, I hereby mark this bug as wontfix. I
will not recommend upstream author to implement this.




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#282184: More information needed for this bug

[Vincent Lefevre]

On 2005-09-28 07:21:22 +0200, Christian Perrier wrote:
> ("addgroup should not refuse adding groups that already exist with the
> same name in an external database such as NIS")

You could possibly add the following condition: the gid is the same one.

> > > I see no real problem in this. Which behaviour are you actually
> > > expecting?
> > 
> > The group should be created in the local database, as the user
> > requested it.
> 
> Uh.
> 
> I'm damn sure this is not a so good idea. For instance high level
> utilities such as  adduser will probably at some moment include
> support for external databases such as LDAP (or NIS...if someone is
> still using this). I really wonder how they could behave in the case
> two groups with the same name exist in both database:
> 
> addgroup toto spaces
> 
> -->in which of the two "spaces" group should toto be added?

The database that has the precedence to look for the "spaces" gid is
given by the nsswitch.conf file; in general, it is /etc/group.

> So, in short, I think that passwd utilities are right using the getent
> calls to get the list of what exists and what doesn't.

I don't think so. getent may use remote databases, whereas groupadd
is purely local (according to the man page).

And some packages use it to create local groups.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / SPACES project at LORIA


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#282184: More information needed for this bug

[Christian Perrier]

("addgroup should not refuse adding groups that already exist with the
same name in an external database such as NIS")

> > I see no real problem in this. Which behaviour are you actually
> > expecting?
> 
> The group should be created in the local database, as the user
> requested it.

Uh.

I'm damn sure this is not a so good idea. For instance high level
utilities such as  adduser will probably at some moment include
support for external databases such as LDAP (or NIS...if someone is
still using this). I really wonder how they could behave in the case
two groups with the same name exist in both database:

addgroup toto spaces

-->in which of the two "spaces" group should toto be added?

So, in short, I think that passwd utilities are right using the getent
calls to get the list of what exists and what doesn't.

Tomasz, comments ?

Bug#282184: More information needed for this bug

[Christian Perrier]

I'm afraid I'm having hard times actually understanding the exact
details of this bug report.

The only information we have is:

# groupadd -g 108 spaces
groupadd: group spaces exists

but one can see that it isn't in /etc/group yet:

# groupmod -g 108 spaces
groupmod: spaces not found in /etc/group

It is necessary to add the group in /etc/group in order to avoid
a possible clash in the future, as groups are sometimes added to
/etc/group when new packages are installed.


As I understand from the bug title there's a "spaces" group in the NIS
database and groupadd refuses to add one in the local
databasewhile groupmod refuses to modify it.

Both probably because "getent group" returns a list including "spaces".

I see no real problem in this. Which behaviour are you actually
expecting?


-- 




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]