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
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
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
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
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
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
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:
> 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
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
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
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
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:
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
>
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
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
15 matches
Mail list logo