On Mon, Feb 29, 2016 at 10:05:03AM -0700, Todd C. Miller wrote:
> On Mon, 29 Feb 2016 09:55:45 -0700, "Todd C. Miller" wrote:
>
> > Most of the PRIV_START / PRIV_END should be removed. There are a
> > few instances where we need to drop setgid when opening files,
> > however. Removing those call
On Mon, 29 Feb 2016 09:55:45 -0700, "Todd C. Miller" wrote:
> Most of the PRIV_START / PRIV_END should be removed. There are a
> few instances where we need to drop setgid when opening files,
> however. Removing those calls needs to be done very carefully.
It is also worth rethinking whether lp
On Mon, 29 Feb 2016 09:48:32 -0700, Theo de Raadt wrote:
> PRIV_START / PRIV_END is not privsep by any means. It is the
> old cron-style "drop id, do action, regain id" model.
Most of the PRIV_START / PRIV_END should be removed. There are a
few instances where we need to drop setgid when openin
PRIV_START / PRIV_END is not privsep by any means. It is the
old cron-style "drop id, do action, regain id" model.
I don't think you understand what is being done here.
> I have a diff out there right now on these files but I noticed the
> following:
>
>
> /*
> * Scan the current directory an
I have a diff out there right now on these files but I noticed the
following:
/*
* Scan the current directory and make a list of daemon files sorted by
* creation time.
* Return the number of entries and a pointer to the list.
*/
int
getq(struct queue ***namelist)
{
struct dirent *d;
