Date:	Sun, 20 May 2001 17:34:13 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: ANNOUNCE: Fileutils 4.0 beta 2
In-Reply-To:	<3B078E2D.682B95BB@phekda.freeserve.co.uk>
Message-ID:	<Pine.SUN.3.91.1010520172522.23429A-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Sun, 20 May 2001, Richard Dawe wrote:

> I don't like the idea a function of setting the user and group and not
> restoring them, just so the C library "thinks" that we are the specified
> user & group. I think the user and group switch should be local to the
> function. What if other functions also use the user & group? They may
> behave differently if called before/after a function that switches user &
> group.

In theory, yes.  But userspec.c is not a library function, it is only 
used by certain programs, and those programs do their thing and then 
exit.

> > > * It makes all user & group names map to the same uid & gid
> > > respectively. This may be what you want in some cases. But there is no
> > > way to distinguish between current user & group and every other user &
> > > group. In chown and chgrp you want the second behaviour.
> > 
> > I don't think I see why the value of uid and gid matter.
> 
> It's not the values that matter. What matters is that you can distinguish
> between the "owned by me" and "not owned by me" and "in my group" and "not
> in my group" cases.

But in DJGPP, all files are "owned by me".  (They all are also "owned by 
you", for that matter.)  So we cannot distinguish between these two kinds 
anyway.

> > If this gets too complicated to fix in userspec.c, perhaps we should
> > consider fixing it in libc.a.
> 
> I think this is a better way to go. But how would we do it? We could add
> functions to create other users & groups on the fly, e.g.:
> 
>     __add_user("brian", 123);
>     __add_group("root", 0);

Actually, I thought about changing getpwnam etc. so that it would not 
reject users other than specified by $USER.  If so many programs which 
use getpwnam and friends need to work around this, it's a sign that the 
behavior is not useful.

- Raw text -