patch: hide processes non owned by a user

2015-01-26 Thread Renaud Allard
Hello, I wrote a patch which adds a new kernel sysctl (hideproc) to hide processes non owned by a user, except for root. This should be mostly useful on shell servers and on servers with chroots. I know some controversial patches have been presented in the past, but this one only does only o

Re: Following Current / Flag Day

2015-01-26 Thread STeve Andre'
On 01/27/15 00:16, Theo de Raadt wrote: On 01/26/15 19:34, Kurt Miller wrote: We narrowed the definition of what a static pie binary is in the kernel. This change is a flag day where newer kernels will not recognize older pie binaries making upgrading via source hard. If you are running an older

Re: Following Current / Flag Day

2015-01-26 Thread Theo de Raadt
>On 01/26/15 19:34, Kurt Miller wrote: >> We narrowed the definition of what a static pie binary is in the kernel. >> This change is a flag day where newer kernels will not recognize older >> pie binaries making upgrading via source hard. If you are running an >> older version of -current, upgrade

Re: Following Current / Flag Day

2015-01-26 Thread STeve Andre'
On 01/26/15 19:34, Kurt Miller wrote: We narrowed the definition of what a static pie binary is in the kernel. This change is a flag day where newer kernels will not recognize older pie binaries making upgrading via source hard. If you are running an older version of -current, upgrade via snapsho

Re: elantech-v4 clickpad support

2015-01-26 Thread Ulf Brosziewski
On 01/25/2015 04:07 PM, Alexandr Shadchin wrote: On Wed, Jan 14, 2015 at 12:23:13AM +0100, Ulf Brosziewski wrote: Currently pms and the wsconscomm module of the synaptics driver offer a somewhat limited support for Elantech clickpads with hardware version 4. Above all, I missed the options of pe

Following Current / Flag Day

2015-01-26 Thread Kurt Miller
We narrowed the definition of what a static pie binary is in the kernel. This change is a flag day where newer kernels will not recognize older pie binaries making upgrading via source hard. If you are running an older version of -current, upgrade via snapshots prior to building a new kernel from s

Re: machine with a zzz problem with lidsuspend=1

2015-01-26 Thread Mike Larkin
On Tue, Jan 27, 2015 at 12:11:35AM +0100, Mark Kettenis wrote: > > Date: Mon, 26 Jan 2015 22:30:02 + > > From: Stuart Henderson > > > > On 2015/01/26 23:18, Mark Kettenis wrote: > > > > Date: Mon, 26 Jan 2015 21:17:33 + > > > > From: Stuart Henderson > > > > > > > > This machine (server

Re: machine with a zzz problem with lidsuspend=1

2015-01-26 Thread Mark Kettenis
> Date: Mon, 26 Jan 2015 22:30:02 + > From: Stuart Henderson > > On 2015/01/26 23:18, Mark Kettenis wrote: > > > Date: Mon, 26 Jan 2015 21:17:33 + > > > From: Stuart Henderson > > > > > > This machine (server-ish hw used as a desktop) used to suspend and > > > resume nicely, but followi

Re: machine with a zzz problem with lidsuspend=1

2015-01-26 Thread Stuart Henderson
On 2015/01/26 23:18, Mark Kettenis wrote: > > Date: Mon, 26 Jan 2015 21:17:33 + > > From: Stuart Henderson > > > > This machine (server-ish hw used as a desktop) used to suspend and > > resume nicely, but following the lidsuspend change no longer resumes > > (machine powers up, screen stays b

Re: machine with a zzz problem with lidsuspend=1

2015-01-26 Thread Mark Kettenis
> Date: Mon, 26 Jan 2015 21:17:33 + > From: Stuart Henderson > > This machine (server-ish hw used as a desktop) used to suspend and > resume nicely, but following the lidsuspend change no longer resumes > (machine powers up, screen stays black). > > It works correctly if machdep.lidsuspend i

machine with a zzz problem with lidsuspend=1

2015-01-26 Thread Stuart Henderson
This machine (server-ish hw used as a desktop) used to suspend and resume nicely, but following the lidsuspend change no longer resumes (machine powers up, screen stays black). It works correctly if machdep.lidsuspend is set to 0. I can run like that without a problem but it would be nicer to fix

ntpd: adjtime variations between OSes

2015-01-26 Thread Brent Cook
Hi, Paul and I have been doing some testing of OpenNTPD on various OSes, and found some interesting deviations. Paul noted that running the latest OpenNTPD-portable on OmniOS (Solaris derivative) that it would cycle back and forth between 'clock is now synced' and 'clock is now unsynced'. So, we p

Re: PATCH: NAT on IPSec

2015-01-26 Thread Vincent Gross
On Thu, Jan 15, 2015 at 04:00:20PM +0100, Vincent Gross wrote: > Hello folks, > > This patch brings nat capabilites into iked, the same way that mpf@ did > with isakmpd about 6 years ago. > > Comments ? bumpity bump bump. Any comments on this ? > > Tested with the following setup, with icmp,

Re: elantech-v4 clickpad support

2015-01-26 Thread Martin Pieuchot
On 25/01/15(Sun) 20:07, Alexandr Shadchin wrote: > On Wed, Jan 14, 2015 at 12:23:13AM +0100, Ulf Brosziewski wrote: > [...] > Sorry for the long answer. > > I tested xenocara part on x201(synaptics touchpad) and x220(synaptics > clickpad), > this works, no regress, even works click-and-drag :) >

Do not let umass(4) insult you

2015-01-26 Thread Martin Pieuchot
Some HTC phones first present a Umass descriptor when they're attached to a machine then disconnect them self and reattach with an Imaging (MTP) descriptor. In between they stop answering to umass(4) which vomit some of its best prose: umass0: BBB reset failed, IOERROR umass0: BBB

Re: Use rtdeletemsg()

2015-01-26 Thread Martin Pieuchot
On 23/01/15(Fri) 19:59, Alexander Bluhm wrote: > On Mon, Jan 19, 2015 at 11:49:53AM +0100, Martin Pieuchot wrote: > > Instead of rerolling rtrequest1(RTM_DELETE...) code in various places, > > I am a fan of code unification. > > > simply use rtdeletemsg() which also notify userland that the route

Re: [patch] xdm doesn't clear wtmp/utmp entry after log out

2015-01-26 Thread Jérémie Courrèges-Anglas
Matthieu Herrb writes: > On Tue, Jan 13, 2015 at 01:38:36PM -0800, patrick keshishian wrote: [...] > Makes sense. ok matthieu@ Committed, thanks. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE