Date: Sun, 20 May 2001 17:34:13 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Richard Dawe 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: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk 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.