On 2024-12-19 22:00, Wietse Venema via Postfix-users wrote:
>
> This is not the privilege escalation or loss that I had in mind. If you
> don't want some user to have .forward files, edit main.cf:forward_path
> and use pathnames that depend on $user instead of $home.
I'm not saying it is. Just th
Tomasz Pala via Postfix-users:
> On 2024-12-19 17:53, Wietse Venema via Postfix-users wrote:
> >
> > **HOWEVER** when Postfix runs a non-Postfix code on behalf of a
> > user (example: a command in a .forward file) THEN IT WOULD BE A
> > REAL WTF if that command has different rights than the user.
On 2024-12-19 17:53, Wietse Venema via Postfix-users wrote:
>
> **HOWEVER** when Postfix runs a non-Postfix code on behalf of a
> user (example: a command in a .forward file) THEN IT WOULD BE A
> REAL WTF if that command has different rights than the user. If
> the command CAN do something that t
On 2024-12-19 08:39, Michael Tokarev via Postfix-users wrote:
>
> I don't see a reason to play with capabilities outside of postfix source
> code: it is ineffective. If we're to adopt capabilities, we should teach
> postfix itself to manipulate them on per-service or per-context basis.
I doubt y
Michael Tokarev via Postfix-users:
> 18.12.2024 01:12, Wietse Venema via Postfix-users wrote:
>
> > Just for the record, Postfix requires that a system behaves as
> > defined in POSIX (and ANSI C). That remains the baseline for what
> > calls are expected to succeed, and for what calls are expecte
Having written all this, I'd love to note once again: this was just a
small experiment, which has shown it we're to work in this area, it
should be done within postfix, not outside it, and due to its well-
thought architecture, this seems to be doable (keeping the same
well-thought architecture).
17.12.2024 13:25, Tomasz Pala via Postfix-users wrote:
Disregarding this (e.g. LMTP, virtual mailboxes only) one could try to
directly start with:
User=postfix
AmbientCapabilities=...
which would make in turn this unnecessary:
setfacl -m user:root:rwx $queue_directory/public
With current
18.12.2024 01:12, Wietse Venema via Postfix-users wrote:
Just for the record, Postfix requires that a system behaves as
defined in POSIX (and ANSI C). That remains the baseline for what
calls are expected to succeed, and for what calls are expected to
fail.
This is one of the possible views on
Michael Tokarev via Postfix-users:
> On 17.12.2024 18:14, Wietse Venema via Postfix-users wrote:
> > Did you verify the non-daemon programs, specifically that all
> > featrues work as promised in sendmail, postdrop, postqueue, postsuper,
> > postmap, postalias, and postcat? Be sure to also test as
On 17.12.2024 18:14, Wietse Venema via Postfix-users wrote:
Did you verify the non-daemon programs, specifically that all
featrues work as promised in sendmail, postdrop, postqueue, postsuper,
postmap, postalias, and postcat? Be sure to also test as a non-root
and non-postfix user.
Did you test
Did you verify the non-daemon programs, specifically that all
featrues work as promised in sendmail, postdrop, postqueue, postsuper,
postmap, postalias, and postcat? Be sure to also test as a non-root
and non-postfix user.
Did you test the privilege-changing features of local(8), pipe(8)
and spawn
On 2024-12-17 12:52, Tomasz Pala via Postfix-users wrote:
> On 2024-12-17 11:59, Michael Tokarev via Postfix-users wrote:
>>>
>>> How about direct delivery to /var/mail/$user?
>>
>> I'm not sure I understand. What are you talking about here? Postfix's
>> local(8) can do direct delivery just fine.
On 2024-12-17 11:59, Michael Tokarev via Postfix-users wrote:
>>
>> How about direct delivery to /var/mail/$user?
>
> I'm not sure I understand. What are you talking about here? Postfix's
> local(8) can do direct delivery just fine.
Without cap_dac_override it won't.
Consider (and remember to c
17.12.2024 13:25, Tomasz Pala via Postfix-users wrote:
On 2024-12-17 06:41, Michael Tokarev via Postfix-users wrote:
and repeated mentions about systemd and "real security", I decided to
Well, to be honest, mantra must be repeated - "it's not about security",
like nothing is being guaranteed (
On 2024-12-17 06:41, Michael Tokarev via Postfix-users wrote:
> and repeated mentions about systemd and "real security", I decided to
Well, to be honest, mantra must be repeated - "it's not about security",
like nothing is being guaranteed (for various reasons) and "real
security" must be applied
Good morning,
Am 17.12.2024 um 06:41 schrieb Michael Tokarev via Postfix-users:
...
capabilities of the service which aren't needed. Obviously, postfix
does not need an ability to reboot a system (does it not? How about
sending a special email which will trigger a reboot?) or to do many
My s
16 matches
Mail list logo
