Re: uh oh [Roland.Schwingel@onevision.de: Re: bash broken with cygwin 1.3.20? - now working with 1.3.20]

["Pierre A. Humblet" <Pierre dot Humblet at ieee dot org>]

Corinna Vinschen wrote:
> 
> On Thu, Feb 13, 2003 at 10:08:30AM -0500, Pierre A. Humblet wrote:
> > Christopher Faylor wrote:
> > > Ok, what's causing these type of problems in 1.3.20?  There has been a
> > > few of these reported.
> >
> > > > Please post the output of 'ls -l ../gcc-3.2.1/configure.in'.
> > > -rwx------+   1 Administ Entwickl    55070 Jul  8  2002
> > > ../gcc-3.2.1-ov/configure.in
> >
> > Not sure how bash looks up the access mode.
> > I have some evidence that access() is broken but can't debug until tonight.
> 
> I can't reproduce it.  I've changed an executable to have the above
> permissions and the admins group as owner and I was able to call
> the executable with any of the shells, ash, bash and tcsh.

I haven't tried to reproduce it but there is definitely a bug in internal_getgroups
(introduced on 2003-02-04), which may explain it. Patch on the way.

Also looking at the logic in acl_access
      if ((!(flags & R_OK) || (acls[i].a_perm & S_IROTH))
	  && (!(flags & W_OK) || (acls[i].a_perm & S_IWOTH))
	  && (!(flags & X_OK) || (acls[i].a_perm & S_IXOTH)))
	return 0;
it looks like we only return OK if a single acl grants all the requested rights,
but we fail if say one acl grants R_OK and another one grants W_OK and we need
both.
I am thinking of redoing acl_access by using the MS AccessCheck() function.
This will take care of the issue above, make the call completely independent of 
the passwd and group files and better handle access_denied ACE's.
Any thought?

Pierre