Re: /usr/libexec/security symlink permission check warnings

On Tue, Apr 12, 2016 at 01:53:58AM +0200, Ingo Schwarze wrote: > Hi Antoine, > > Antoine Jacoutot wrote on Mon, Apr 11, 2016 at 07:52:15AM +0200: > > Ingo Schwarze wrote: > > >> Changing which mode is checked won't help you because security(8) > >> also complains that printcap(5) is a symlink

Re: /usr/libexec/security symlink permission check warnings

Hi Stuart, Stuart Henderson wrote on Sun, Apr 10, 2016 at 09:27:06PM +0100: > Between that, a few files where I have slightly wider read > permissions for operational reasons, Which are those? Would it maybe make sense to weaken these checks for everybody? If those permissions make sense for

Re: /usr/libexec/security symlink permission check warnings

Hi Antoine, Antoine Jacoutot wrote on Mon, Apr 11, 2016 at 07:52:15AM +0200: > Ingo Schwarze wrote: >> Changing which mode is checked won't help you because security(8) >> also complains that printcap(5) is a symlink rather than the expected >> regular file. So you would still et spammed. >>

Re: regression with pms.c revision 1.69

Ignore this for now. this may be (probably is) due to the fact X driver is out of sync with the kernel. i'll report back after I build a new set of X, or better yet, try a new snapshot. --patrick On 4/11/16, patrick keshishian wrote: >>Synopsis: regression with -r1.69

regression with pms.c revision 1.69

>Synopsis: regression with -r1.69 pms0 w/Synaptics touchpad lenovo x120e >Category: kernel pms driver >Environment: System : OpenBSD 5.9 Details : OpenBSD 5.9-current (GENERIC.MP) #3: Mon Apr 11 14:16:42 PDT 2016

panic on i386 5.9 with dhclient on bridge

Trying out bridges... didn't have the working right, but this shouldn't panic. soekris 4801 (probably doesn't matter)... very short. OpenBSD 5.9 (GENERIC) #1561: Fri Feb 26 01:22:37 MST 2016 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Geode(TM) Integrated

Re: [bug?] pthread_barrier_wait

Paul Irofti wrote: > > What do you think? > > I think this diff is even safer: it checks for threads entering and > exiting the barrier while holding the mutex, and if both values are 0 it > proceeds to destroy the barrier. > > I also renamed sofar to in so that the relationship between threads