On Fri, 01 Jan 2016 10:55:14 -0800, Philip Guenther wrote:
> Finally got back to this; this diff should fix open(O_NONBLOCK) of bpf,
> tun, and tap devices. The bikeshed question is whether this should use
> O_NONBLOCK or FNONBLOCK...
OK millert@ though I would have used FNONBLOCK.
- todd
I'm sorry for delay.
ok yasuoka
tested.
On Fri, 1 Jan 2016 10:55:14 -0800
Philip Guenther wrote:
> On Fri, 4 Dec 2015, Todd C. Miller wrote:
>> On Fri, 04 Dec 2015 09:47:46 -0800, Philip Guenther wrote:
>> > We should fix open(2); please try the diff below. Are you sure pppx
>> > is affected?
On Fri, 4 Dec 2015, Todd C. Miller wrote:
> On Fri, 04 Dec 2015 09:47:46 -0800, Philip Guenther wrote:
> > We should fix open(2); please try the diff below. Are you sure pppx
> > is affected? pppxioctl()'s FIONBIO case appears to be a no-op. I
> > certainly agree that bpf and tun are affected.
>
On Fri, 4 Dec 2015 09:47:46 -0800
Philip Guenther wrote:
> On Fri, Dec 4, 2015 at 3:41 AM, YASUOKA Masahiko wrote:
>> On Sat, 10 Oct 2015 21:32:29 -0700
>> Philip Guenther wrote:
>>> So:
>>> * kill the 'mode' argument to PRIVSEP_OPEN and priv_open()
>>> * fail a PRIVSEP_OPEN call if it's pass
On Fri, 04 Dec 2015 09:47:46 -0800, Philip Guenther wrote:
> We should fix open(2); please try the diff below. Are you sure pppx
> is affected? pppxioctl()'s FIONBIO case appears to be a no-op. I
> certainly agree that bpf and tun are affected.
Shouldn't the device open function check for FNON
On Fri, Dec 4, 2015 at 3:41 AM, YASUOKA Masahiko wrote:
> On Sat, 10 Oct 2015 21:32:29 -0700
> Philip Guenther wrote:
>> So:
>> * kill the 'mode' argument to PRIVSEP_OPEN and priv_open()
>> * fail a PRIVSEP_OPEN call if it's passed any flags other than
>>O_ACCMODE or O_NONBLOCK
>> * parano
Hi,
On Sat, 10 Oct 2015 21:32:29 -0700
Philip Guenther wrote:
> So:
> * kill the 'mode' argument to PRIVSEP_OPEN and priv_open()
> * fail a PRIVSEP_OPEN call if it's passed any flags other than
>O_ACCMODE or O_NONBLOCK
> * paranoia: mask O_CREAT when calling open() with only two arguments
ok yasuoka, the diff is tested.
On Sat, 10 Oct 2015 21:58:02 -0700
Philip Guenther wrote:
> On Sat, 10 Oct 2015, Theo de Raadt wrote:
>> I don't know the code either, but it is probably better if privsep's had
>> more narrow task-specific operations. Like open-specific-file-for-read,
>> and op
On Sat, 10 Oct 2015, Theo de Raadt wrote:
> I don't know the code either, but it is probably better if privsep's had
> more narrow task-specific operations. Like open-specific-file-for-read,
> and open log-over-there. Privsep operations should be tightly
> specified, not very generic.
>
> The
> Currently, npppd's PRIVSEP_OPEN message (abstracted as priv_open())
> accepts arbitrary open() flags and passes a mode argument. That
> seems...unwise.
>
> In particular, it never passes O_CREAT, so the mode argument isn't needed.
> Indeed, the only open 'flags' it needs are O_RDONLY and O_
Currently, npppd's PRIVSEP_OPEN message (abstracted as priv_open())
accepts arbitrary open() flags and passes a mode argument. That
seems...unwise.
In particular, it never passes O_CREAT, so the mode argument isn't needed.
Indeed, the only open 'flags' it needs are O_RDONLY and O_RDWR. If we
11 matches
Mail list logo
