Re: cardbus fix

2015-07-20 Thread Mike Larkin
On Mon, Jul 20, 2015 at 02:48:22AM +0200, Mark Kettenis wrote: > Some (early) acpi machines leave the cardbus bridge unconfigured. In > particular, those machines don't configure the bus number for the > cardbus bus. This makes our driver skip attaching the 32-bit cardbus > handling and only supp

tame(1), like nice(1) but for permissions

2015-07-20 Thread Jeremy Evans
I'm not sure if this makes sense, since tame(2) was designed to operate on processes after they have already been initialized, and this would set the allowed operations before initializing the process. It's a fairly simple change to get the basics working as shown here, but it's currently not very

Re: tame(1), like nice(1) but for permissions

2015-07-20 Thread Nicholas Marriott
Hi I'm not sure I can think of many uses for this, tame is not something you are intended to just apply blindly, do you have any use cases? I think the -aCcdghIiRSptuw approach is a bad idea and it would be better to do it with named flags like -o abort,cmsg,cpath. Maybe take a look at getsubopt(

Re: httpd: hsts (rfc 6797)

2015-07-20 Thread sid77
- Original Message - > There is a non-standard preload token that Google requires to get onto > Chrome's HSTS preload list[0] which is also used by Firefox. Any chance > of supporting this? Or is its omission a conscious decision? > > > [0] https://hstspreload.appspot.com/ > > FWIW, fr

Re: Missing descriptor in uvideo.h

2015-07-20 Thread ludovic coues
There is a typo with struct usb_video_output_header_desc, corresponding to table 3-15. Last field should be bmaControls. -- Cordialement, Coues Ludovic +336 148 743 42

doas failsafe

2015-07-20 Thread Manuel Giraud
Hi, I've just shot myself in the foot after /etc/doas.conf tweaking. This patch adds a failsafe "permit :wheel" rule in case of syntax error. Is this safe enough? Should it be done elsewhere (with some kind of visudo)? Index: doas.c

Re: doas failsafe

2015-07-20 Thread Ted Unangst
Manuel Giraud wrote: > Hi, > > I've just shot myself in the foot after /etc/doas.conf tweaking. This > patch adds a failsafe "permit :wheel" rule in case of syntax error. Is > this safe enough? Should it be done elsewhere (with some kind of > visudo)? I think the failsafe is "run su". Since it is

Re: Missing descriptor in uvideo.h

2015-07-20 Thread Martin Pieuchot
On 15/07/15(Wed) 17:30, ludovic coues wrote: > 2015-07-15 17:04 GMT+02:00 Martin Pieuchot : > > On 15/07/15(Wed) 16:45, Ludovic Coues wrote: > >> Following is a diff adding missing USB descriptor to uvideo.h according > >> to USB Video spec 1.5 . It also update a couple of table reference from > >>

Re: Clarification on bgpd behaviour

2015-07-20 Thread Pedro Caetano
i'm replying to this thread so people browsing archives do not read deprecated info. The recent commits on kroute fixes the issue reported. When the interface is down the local link is no longer listed in the routing table. Thank you for your work! On Thu, Jan 15, 2015 at 11:23 PM, Pedro Caetan

Re: tame(1), like nice(1) but for permissions

2015-07-20 Thread Jeremy Evans
On 07/20 09:36, Nicholas Marriott wrote: > Hi > > I'm not sure I can think of many uses for this, tame is not something > you are intended to just apply blindly, do you have any use cases? Well, there is the example in the man page. :) But no, currently it's not very useful, as more complex progr

Re: tame(1), like nice(1) but for permissions

2015-07-20 Thread Ted Unangst
Jeremy Evans wrote: > > If this is worthy of more work, the command line options can certainly > be changed. I just used getopt(3) since it seemed like the easiest > way to handle it. I talked with theo about this some. I'd say it's probably too early, and may lead us down a weird path, where ta

Re: tame(1), like nice(1) but for permissions

2015-07-20 Thread Marc Espie
On Mon, Jul 20, 2015 at 12:04:43PM -0400, Ted Unangst wrote: > chroot is probably the best comparision. yes, we provide a chroot(1), but There is no chroot(1). :p > practically nothing uses it. everything is instead calling chroot(2) on its > own. the things that do use chroot(1) are doing so for

Re: tame(1), like nice(1) but for permissions

2015-07-20 Thread Theo de Raadt
> On Mon, Jul 20, 2015 at 12:04:43PM -0400, Ted Unangst wrote: > > chroot is probably the best comparision. yes, we provide a chroot(1), but > There is no chroot(1). :p > > > practically nothing uses it. everything is instead calling chroot(2) on its > > own. the things that do use chroot(1) are d

Re: move pflow(4) to sosend(9)

2015-07-20 Thread Alexander Bluhm
On Mon, Jul 20, 2015 at 01:09:07AM +, Florian Obser wrote: > so pflow(4) shoving it's data with ip_output into the network stack > seems wrong. this converts it to use sosend(9) and might even give us > non-legacy IP support. I think this is a good idea. Comments inline. bluhm > tests from

Re: tame(1), like nice(1) but for permissions

2015-07-20 Thread Marc Espie
On Mon, Jul 20, 2015 at 10:41:08AM -0600, Theo de Raadt wrote: > > On Mon, Jul 20, 2015 at 12:04:43PM -0400, Ted Unangst wrote: > > > chroot is probably the best comparision. yes, we provide a chroot(1), but > > There is no chroot(1). :p > > > > > practically nothing uses it. everything is instead

Re: tame(1), like nice(1) but for permissions

2015-07-20 Thread Theo de Raadt
> Sorry, should have made things clearer. I just meant that chroot was > a bad comparison. I can't see any sane use of a tame(1) at the > moment. No, no no, Ted's comments are completely valid. You cannot replace the narrow chroot calls in the privsep daemons with chroot(8) run externally. Any

Re: move pflow(4) to sosend(9)

2015-07-20 Thread Florian Obser
On Mon, Jul 20, 2015 at 06:58:06PM +0200, Alexander Bluhm wrote: > On Mon, Jul 20, 2015 at 01:09:07AM +, Florian Obser wrote: > > - s = splnet(); > > > > + s = splnet(); > > pflow_flush(sc); > > + splx(s); > > This splx() looks strange, too. Why flu

Octeon flash driver for DSR500

2015-07-20 Thread Paul Irofti
Here is a diff that adds a new flash driver for octeon that allows me to access the internal memory of my DSR500. This follows the CFI specification with code borrowed from zrouter (FreeBSD). The idea, once the current driver is thoroughly tested, would be to move it to MI land. The prerequisites

Re: [PATCH] Fix ospfd segmentation fault on startup

2015-07-20 Thread Johan Ymerson
On 2015-07-18 16:03:00, Martin Pieuchot wrote: > Committed! Thanks and sorry for the delay. Hi! You missed the previous patch "Fix ospfd segmentation fault on startup" witch prevent ospfd from segfaulting on startup. Without this first patch, ospfd will almost always segfault on startup (instead

Re: [PATCH] Fix ospfd segmentation fault on startup

2015-07-20 Thread Martin Pieuchot
On 20/07/15(Mon) 19:10, Johan Ymerson wrote: > On 2015-07-18 16:03:00, Martin Pieuchot wrote: > > Committed! Thanks and sorry for the delay. > > Hi! > > You missed the previous patch "Fix ospfd segmentation fault on startup" > witch prevent ospfd from segfaulting on startup. Without this first >

Re: [PATCH] Fix ospfd segmentation fault on startup

2015-07-20 Thread Johan Ymerson
On Mon, 2015-07-20 at 22:58 +0200, Martin Pieuchot wrote: > On 20/07/15(Mon) 19:10, Johan Ymerson wrote: > > On 2015-07-18 16:03:00, Martin Pieuchot wrote: > > > Committed! Thanks and sorry for the delay. > > > > Hi! > > > > You missed the previous patch "Fix ospfd segmentation fault on startup"

Re: move pflow(4) to sosend(9)

2015-07-20 Thread Florian Obser
new diff, should address all comments: diff --git if_pflow.c if_pflow.c index 4f3ac5e..676829d 100644 --- if_pflow.c +++ if_pflow.c @@ -28,6 +28,8 @@ #include #include #include +#include +#include #include #include @@ -68,10 +70,7 @@ int pflow_clone_destroy(struct ifnet *); void

Re: [PATCH] Fix ospfd segmentation fault on startup

2015-07-20 Thread Claudio Jeker
On Mon, Jul 20, 2015 at 09:32:20PM +, Johan Ymerson wrote: > On Mon, 2015-07-20 at 22:58 +0200, Martin Pieuchot wrote: > > On 20/07/15(Mon) 19:10, Johan Ymerson wrote: > > > On 2015-07-18 16:03:00, Martin Pieuchot wrote: > > > > Committed! Thanks and sorry for the delay. > > > > > > Hi! > > >

Re: move pflow(4) to sosend(9)

2015-07-20 Thread Alexander Bluhm
On Mon, Jul 20, 2015 at 09:58:03PM +, Florian Obser wrote: > + tso = sc->so; > + sc->so = so; > + soclose(tso); The tso dance is not neccessary. simply soclose(sc->so); sc->so = so; otherwise OK bluhm@

fix iwm(4) newstate task (was: Re: iwm(4): make iwm_newstate() interrupt safe)

2015-07-20 Thread Stefan Sperling
On Sun, Jul 19, 2015 at 04:32:39AM +0200, Stefan Sperling wrote: > Please test this if you use iwm(4). It should make the driver more > reliable, e.g. when bringing the interface up which sometimes fails > because of... reasons. Please test this updated diff instead. The previous one had races bet

Re: [PATCH] Fix ospfd segmentation fault on startup

2015-07-20 Thread Sebastian Benoit
Johan Ymerson(johan.ymer...@transmode.com) on 2015.07.20 21:32:20 +: > On Mon, 2015-07-20 at 22:58 +0200, Martin Pieuchot wrote: > > On 20/07/15(Mon) 19:10, Johan Ymerson wrote: > > > On 2015-07-18 16:03:00, Martin Pieuchot wrote: > > > > Committed! Thanks and sorry for the delay. > > > > > >

Re: doas failsafe

2015-07-20 Thread lists
> I think the failsafe is "run su". Visudo(8) style wrapper for doas(1) that would respect the editor preferences... is only a suggestion, no? We're 2015 here. > Since it is possible to configure doas to > even less than "permit :wheel" this would in some cases be a fail open. I'm not sure how m

fixes for coverity warnings to cat(1)

2015-07-20 Thread Sevan Janiyan
Hi, Attached is a diff for a couple of issues raised by coverity, obtained from NetBSD src/bin/cat/cat.c r1.53 & r1.54 >From the commit message in NetBSD CVS: "bin/cat/cat.c 976654 Argument cannot be negative (missing check for fileno result, stdout) bin/cat/cat.c 976653 Impro

Re: doas failsafe

2015-07-20 Thread Ted Unangst
li...@wrant.com wrote: > > I think the failsafe is "run su". > > Visudo(8) style wrapper for doas(1) that would respect the editor > preferences... is only a suggestion, no? We're 2015 here. and vipf after that? there are countless config files, even more dangerous than doas.conf, that you edit a

Re: feed l4 information into trunk(4) hash

2015-07-20 Thread Stuart Henderson
On 2014/12/12 10:48, Sebastian Benoit wrote: > Stuart Henderson(st...@openbsd.org) on 2014.12.11 23:52:44 +: > > I'm wondering what reception this will get. It feeds TCP/UDP port > > numbers into the hash for trunk(4) load balancing, so connections > > between a single pair of hosts will get di

Re: doas failsafe

2015-07-20 Thread lists
> > > I think the failsafe is "run su". > > > > Visudo(8) style wrapper for doas(1) that would respect the editor > > preferences... is only a suggestion, no? We're 2015 here. > > and vipf after that? there are countless config files, even more dangerous > than doas.conf, that you edit at your ow

Re: [PATCH] Fix ospfd segmentation fault on startup

2015-07-20 Thread Sebastian Benoit
commited, thx for your diff. /Benno Johan Ymerson(johan.ymer...@transmode.com) on 2015.07.20 21:32:20 +: > On Mon, 2015-07-20 at 22:58 +0200, Martin Pieuchot wrote: > > On 20/07/15(Mon) 19:10, Johan Ymerson wrote: > > > On 2015-07-18 16:03:00, Martin Pieuchot wrote: > > > > Committed! Thanks

Re: doas failsafe

2015-07-20 Thread tekk
On Mon, Jul 20, 2015 at 04:36:45PM -0700, lists wrote: > So why can't "allow" fit as opposite to deny? (normally silence means > no change in security model, hopefully). I'm a lowly user but I ++ this, when testing out doas I did this a few times. allow : deny, permit : forbid

Re: doas failsafe

2015-07-20 Thread lists
> I'm a lowly user but I ++ this, when testing out doas I did this a few > times. allow : deny, permit : forbid Is that you, Flynn?

Re: doas failsafe

2015-07-20 Thread Stuart Henderson
On 2015/07/20 19:18, Ted Unangst wrote: > li...@wrant.com wrote: > > > I think the failsafe is "run su". > > > > Visudo(8) style wrapper for doas(1) that would respect the editor > > preferences... is only a suggestion, no? We're 2015 here. > > and vipf after that? there are countless config file

Re: doas failsafe

2015-07-20 Thread Manuel Giraud
"Ted Unangst" writes: > Manuel Giraud wrote: >> Hi, >> >> I've just shot myself in the foot after /etc/doas.conf tweaking. This >> patch adds a failsafe "permit :wheel" rule in case of syntax error. Is >> this safe enough? Should it be done elsewhere (with some kind of >> visudo)? > > I think th