OpenSMTPD: unprivileged mode

2020-04-26 Thread Christopher Zimmermann
Hi, I further developed my approach to allow running smtpd with fewer privileges. This diff does two things: - always run lmtp deliveries as SMTPD_USER. The change to mda_unpriv.c is needed, because otherwise all mails would be delivered to SMTPD_USER. - add two internal flags NOPRIV

OpenSMTPD: unprivileged mode - now with diff

2020-04-26 Thread Christopher Zimmermann
Hi, I further developed my approach to allow running smtpd with fewer privileges. This diff does two things: - always run lmtp deliveries as SMTPD_USER. The change to mda_unpriv.c is needed, because otherwise all mails would be delivered to SMTPD_USER. - add two internal flags NOPRIV

Re: OpenSMTPD: unprivileged mode - now with diff

2020-04-26 Thread Christopher Zimmermann
On Sun, Apr 26, 2020 at 08:55:14AM +, gil...@poolp.org wrote: April 26, 2020 10:34 AM, "Christopher Zimmermann" wrote: - always run lmtp deliveries as SMTPD_USER. The change to mda_unpriv.c is needed, because otherwise all mails would be delivered to SMTPD_USER. - add two internal

Re: OpenSMTPD: unprivileged mode - now with diff

2020-04-26 Thread gilles
April 26, 2020 10:34 AM, "Christopher Zimmermann" wrote: > Hi, > > I further developed my approach to allow running smtpd with fewer privileges. > This diff does two > things: > > - always run lmtp deliveries as SMTPD_USER. The change to mda_unpriv.c is > needed, because otherwise > all

Re: correction for insque.3

2020-04-26 Thread Jason McIntyre
On Thu, Apr 23, 2020 at 05:48:42PM -0400, Andras Farkas wrote: > I was reading the thread about STAILQ and SIMPLEQ and thought it was > interesting, so I then read a little about sys/queue.h and search.h > I noticed an error in insque.3: > https://man.openbsd.org/insque.3 > The words "next" and

Re: OpenSMTPD: unprivileged mode - now with diff

2020-04-26 Thread Gregory Edigarov
Hello, Christopher On the right of a person who had successfully run rootless sendmail installations for many years, please find some comments below. On 2020-04-26 12:30, Christopher Zimmermann wrote: Thanks for giving it a thought. I'm not entirely convinced either. But believe some thought

Raspberry Pi GPIO

2020-04-26 Thread Mark Kettenis
Diff below adds GPIO support to bcmgpio(4). It also adds the bits to attach gpio(4) such that GPIO pins can be controlled from userland. This makes sense on boards like the Raspberry Pi and the implementation makes sure that pins used by kernel drivers can't be touched. ok? Index:

Re: coherent em(4) descriptor rings (to be able to run on my arm64 machine)

2020-04-26 Thread Mark Kettenis
> Date: Sun, 26 Apr 2020 18:03:20 +0200 > From: Patrick Wildt > > Hi, > > I have a HummingBoard Pulse, which is an NXP i.MX8MQ based board > featuring two ethernets, with the second ethernet being an em(4) on > a PCIe controller. > > I had trouble getting it to work, but realized that the

smtpd: fix catch-all in virtual aliases

2020-04-26 Thread Eric Faurot
Hi. When a catch-all entry (@) is used in a virtual alias table, it eventually (and mistakenly) catches everything that expands to a username. For example, with: f...@example.com user @catchall "f...@example.com" expands to "user" as expected, but then "user" expands to

coherent em(4) descriptor rings (to be able to run on my arm64 machine)

2020-04-26 Thread Patrick Wildt
Hi, I have a HummingBoard Pulse, which is an NXP i.MX8MQ based board featuring two ethernets, with the second ethernet being an em(4) on a PCIe controller. I had trouble getting it to work, but realized that the issue is the descriptor ring coherency. I looked into the code, tried to find if

Re: [patch] Check for -1 explicitly in getpeereid.c

2020-04-26 Thread Theo de Raadt
If it returns 50 then the creds structure is not valid, and can't be copied from. It only returns valid creds *IF* success is indicated by 0. But then you convert 50 to a return value of 0, and hide any indication that things went weird? No way, I'm not buying your argument. I think the code

Re: [patch] Check for -1 explicitly in getpeereid.c

2020-04-26 Thread Patrick Wildt
Hi, I don't know userland very well, so I have a question. In the middle of 2019 there have been plenty of changes in regards to changing checks of syscalls from < 0 to a more strict == -1, like this one in isakmpd: revision 1.26 date: 2019/06/28 13:32:44; author:

Re: [patch] Check for -1 explicitly in getpeereid.c

2020-04-26 Thread Theo de Raadt
Patrick Wildt wrote: > I don't know userland very well, so I have a question. In the middle of > 2019 there have been plenty of changes in regards to changing checks of > syscalls from < 0 to a more strict == -1, like this one in isakmpd: > > > revision 1.26 >

[patch] Check for -1 explicitly in getpeereid.c

2020-04-26 Thread Martin Vahlensieck
Hi there >From the getsockopt(2) manual page says getsockopt(2) returns -1 on error and 0 on success. Also getpeereid(3) only lists those 2 values. This diff makes the return value check in getpeereid explicit. I guess this is how it is done elsewhere in the tree (there is a commit turning a

Re: acpi interrupt storm on HP EliteBook 840 G1

2020-04-26 Thread Greg Steuck
I searched a bit more and found a few cases when other people reported this behavior: https://marc.info/?l=openbsd-misc=154348280502809=2 https://marc.info/?l=openbsd-bugs=152022260714390=2 I applied a variation of the Thomas Merkel's patch (at the bottom) which took care of the symptoms while