uh oh [Roland.Schwingel@onevision.de: Re: bash broken with cygwin 1.3.20? - now working with 1.3.20]
Pierre A. Humblet
Fri Feb 14 15:48:00 GMT 2003
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)))
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
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.
More information about the Cygwin-developers