Re: rebound quantum entanglement

2016-10-03 Thread Theo de Raadt
+ return sysctl_int(oldp, oldlenp, newp, newlen, ); +int dnsjacking = 0; + sin.sin_port = htons(dnsjacking); How about using u_int16_t or in_port_t; and maybe error out if high bits are set rather than ignoring them but still displaying them.

Re: rebound quantum entanglement

2016-10-03 Thread Ted Unangst
Ted Unangst wrote: > Ted Unangst wrote: > > So the plan is for rebound to be the 'system' resolver, with libc talking to > > rbeound and rebound talking to the cloud. The main wrinkle is how does > > rebound > > find the cloud? rebound.conf, but dhclient doesn't know anything about > >

Re: disklabel template: percentage of disk optional?

2016-10-03 Thread Dmitrij D. Czarkoff
"Dmitrij D. Czarkoff" wrote: >"Dmitrij D. Czarkoff" wrote: > >>"Dmitrij D. Czarkoff" wrote: >> >>>Claus Assmann wrote: >>> AFAICT the "percentage of disk" is optional >>> >>>disklabel(8) says: >>> >>>|

Re: disklabel template: percentage of disk optional?

2016-10-03 Thread Dmitrij D. Czarkoff
"Dmitrij D. Czarkoff" wrote: >"Dmitrij D. Czarkoff" wrote: > >>Claus Assmann wrote: >> >>>AFAICT the "percentage of disk" is optional >> >>disklabel(8) says: >> >>| A template for the automatic allocation can be passed \ >>| to

Re: disklabel template: percentage of disk optional?

2016-10-03 Thread Dmitrij D. Czarkoff
"Dmitrij D. Czarkoff" wrote: >Claus Assmann wrote: > >>AFAICT the "percentage of disk" is optional > >disklabel(8) says: > >| A template for the automatic allocation can be passed \ >| to disklabel using >| the -T option. The template consists of

Re: disklabel template: percentage of disk optional?

2016-10-03 Thread Dmitrij D. Czarkoff
Claus Assmann wrote: >AFAICT the "percentage of disk" is optional disklabel(8) says: | A template for the automatic allocation can be passed to disklabel using | the -T option. The template consists of one line per partition, with | each line giving mountpoint,

Re: Explicitly cast the return variable in tls_load_file()

2016-10-03 Thread kinichiro inoguchi
I could have an answer that this compilation error was a bug of compiler, and that bug will be tracked. https://software.intel.com/en-us/forums/intel-c-compiler/topic/698109 I saw the type of buf was changed in cvs, then I can avoid this compilation problem. Thanks. Kinichiro

disklabel template: percentage of disk optional?

2016-10-03 Thread Claus Assmann
While playing around with the autoinstaller and autodisklayout I ran into several problems, some of which I worked around and for one I created a possible patch, but I'm not sure if that's the right thing to do. I have a disklayout template like this: / 500M swap1G /tmp1G-2G /var

Re: add in6 multicast support to vxlan(4) ; question on mbufs

2016-10-03 Thread Vincent Gross
On Sat, 24 Sep 2016 10:58:10 +0200 Vincent Gross wrote: > Hi, > [snip] > > Aside from the mbuf issue, is this Ok ? I will go back on the mbuff stuff later. Diff rebased, ok anyone ? Index: net/if_vxlan.c ===

Re: Unexpected behavior in su/doas

2016-10-03 Thread Ted Unangst
Simon Ruderich wrote: > Hello, > > I stumbled upon unexpected behavior on OpenBSD 6.0 (all patches) > which seems to allow running commands as the original user when > using su and doas interactively because the controlling terminal > is the same. > Is this behavior expected and if so, how do I

Re: First usages of timeout_set_proc(9)

2016-10-03 Thread Alexander Bluhm
On Mon, Oct 03, 2016 at 02:57:34PM +0200, Martin Pieuchot wrote: > Here are some timeouts that require a process context in order to call > ip_output(). > > The reason is that rtalloc(9) might end up inserting a RTF_CLONING route > and that requires holding a write lock. This isn't going to

Help me testing the netlock

2016-10-03 Thread Martin Pieuchot
Diff below introduces a single write lock that will be used to serialize access to ip_output(). This lock will be then split in multiple readers and writers to allow multiple forwarding paths to run in parallel of each others but still serialized with the socket layer. I'm currently looking for

Re: First usages of timeout_set_proc(9)

2016-10-03 Thread Mark Kettenis
> Date: Mon, 3 Oct 2016 14:57:34 +0200 > From: Martin Pieuchot > > Here are some timeouts that require a process context in order to call > ip_output(). > > The reason is that rtalloc(9) might end up inserting a RTF_CLONING route > and that requires holding a write lock. This

Re: bridge(4): fix span interface removal

2016-10-03 Thread Martin Pieuchot
On 03/10/16(Mon) 15:07, Rafael Zalamena wrote: > While doing the "notify bridge of interface removal with hook" I noticed > that the span ports suffer from not having something to remove them. To > reproduce this problem, do the following steps: > > # ifconfig vether0 up > # ifconfig bridge0 up >

bridge(4): fix span interface removal

2016-10-03 Thread Rafael Zalamena
While doing the "notify bridge of interface removal with hook" I noticed that the span ports suffer from not having something to remove them. To reproduce this problem, do the following steps: # ifconfig vether0 up # ifconfig bridge0 up # ifconfig bridge0 addspan vether0 # ifconfig vether0

First usages of timeout_set_proc(9)

2016-10-03 Thread Martin Pieuchot
Here are some timeouts that require a process context in order to call ip_output(). The reason is that rtalloc(9) might end up inserting a RTF_CLONING route and that requires holding a write lock. This isn't going to change because we're also going to use write locks to protect pf(4) internals.

Re: stricter sys_mount() flag handling

2016-10-03 Thread Alexander Bluhm
On Mon, Oct 03, 2016 at 12:16:49PM +0200, Martin Natano wrote: > > /* > > * Flags set by internal operations. > > */ > > #define MNT_LOCAL 0x1000 /* filesystem is stored locally */ > > #define MNT_QUOTA 0x2000 /* quotas are enabled on filesystem > > */ > > #define

Re: Unexpected behavior in su/doas

2016-10-03 Thread Simon Ruderich
On Sat, Oct 01, 2016 at 03:54:40PM -0600, Theo de Raadt wrote: > De-escalation using these "sudo" or "doas" like tools on a tty is > somewhat unsafe - it has always been unsafe - because tty's have > capabilities. Until looking into this issue I was totally unaware of the possible implications

Re: v6 time_uptime vs time_second

2016-10-03 Thread Stuart Henderson
On 2016/10/02 19:37, Martin Pieuchot wrote: > I'm trying to figure out where the regression in IPv6/NDP is and here's > what I found so far. > > When the route expiration time got converted from time_second to > time_uptime we forgot to do the same for values inside RAs. I'm not > sure what's

Re: stricter sys_mount() flag handling

2016-10-03 Thread Martin Natano
> > And I want this check also for sys_unmount(). > > > > Good idea, sys_mount() is easy, because the only flag allowed there is > MNT_FORCE. s/sys_mount/sys_unmount/