This is the mail archive of the cygwin-patches@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Races in group/passwd code (was Re: etc_changed, passwd & group)


Christopher Faylor wrote:

> You'd need a per-thread buffer to accomplish that.  I assume that
> is what you had in mind.

If you look at them, most internal_get{pw,gr} calls from outside
of passwd.cc and grp.cc only want the {u,g}id, the sid or the name,
but never the other fields. 
I wanted to avoid copying the entire line, at least in the first
two cases.

I was thinking of making the internal functions take a variable
number of arguments. The first would be as today, the second would 
be a control field specifying what is needed, and the others 
(typically only 1) would be pointers to {u,g}id, cygsid or
a name, in a well know order. Those fields would then be filled 
inside the internal_getXX routine.
The problem with "name" is that today we enforce no upperbound
on the length (but it would be easy to do).
I think name is only looked up in seteuid (outside of uinfo, 
where there is no multithreading anyway).

There are also internal cygwin routines outside of passwd.cc
and grp.cc (e.g. in security.cc) that scan the entire 
{passwd, group} file. I don't know how to avoid keeping a 
(reader) lock during the entire operation.
 
> I wonder how many inexplicable "cygwin hangs" issues this is
> responsible for.

Problems only happen when updating passwd/group while a program
is running. At least in case of the recent BSOD, users were
very good correlating the two events.

Pierre


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]