[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.20.13.1801310040250.604@monopod.intra.ispras.ru>
Date: Wed, 31 Jan 2018 00:51:58 +0300 (MSK)
From: Alexander Monakov <amonakov@...ras.ru>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] faccessat: fix error code on setreXid failure
On Tue, 30 Jan 2018, Rich Felker wrote:
>
> AFAIK wait4 can also return due to Stopped status or trace-related
> reasons, not just exit. That was the motivation I think.
We know we are not tracing this child, and stop notifications are only
delivered if WUNTRACED is given in flags, aren't they?
> > - the code seems to assume that the zombie will not be auto-collected even if
> > SIGCHLD disposition is set to SIG_IGN; this sounds logical, but not explicitly
> > documented as far as I can tell;
>
> Indeed, I'm not sure, but I don't know any good fix.
Bring back the pipe (similar to how posix_spawn receives the status)?
> > --- a/src/unistd/faccessat.c
> > +++ b/src/unistd/faccessat.c
> > @@ -25,7 +25,7 @@ static int checker(void *p)
> > int i;
> > if (__syscall(SYS_setregid, __syscall(SYS_getegid), -1)
> > || __syscall(SYS_setreuid, __syscall(SYS_geteuid), -1))
> > - __syscall(SYS_exit, 1);
> > + return sizeof errors/sizeof *errors - 1;
> > ret = __syscall(SYS_faccessat, c->fd, c->filename, c->amode, 0);
> > for (i=0; i < sizeof errors/sizeof *errors - 1 && ret!=errors[i]; i++);
> > return i;
>
> Looks ok except it encodes an assumption that EBUSY is last. It might
> make more sense to goto the errno-searching loop.
Well, the loop also implicitly encodes that assumption anyway: it stops
at the last entry regardless if it matches, making EBUSY the fallback code
for unrecognized SYS_faccessat return values.
The loop will be gone if the pipe method is re-introduced.
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
