From Newsgroup: comp.mail.sendmail

Hello!

I have a Debian unstable system to test.

I noticed that the praliases command only works if
/etc/mail/aliases.db is globally readable.

-rw-r--r-- 1 smmta smmsp 2165 30. Jan 12:17 /etc/mail/aliases.db


I now used strace to track that down:

This is when it works (world readable):

root@deb-test:~# ls -la /etc/mail/aliases.db
-rw-r--r-- 1 smmta smmsp 2165 30. Jan 12:17 /etc/mail/aliases.db root@deb-test:~# strace praliases 2>&1 |grep alias execve("/usr/sbin/praliases", ["praliases"], 0x7ffe430974f0 /* 11 vars */) = 0 newfstatat(AT_FDCWD, "/etc/mail/aliases.db", {st_mode=S_IFREG|0644, st_size=2165, ...}, 0) = 0
newfstatat(AT_FDCWD, "/etc/mail/aliases.db", {st_mode=S_IFREG|0644, st_size=2165, ...}, 0) = 0
openat(AT_FDCWD, "/etc/mail/aliases.db", O_RDONLY) = 4
openat(AT_FDCWD, "/etc/mail/aliases.db", O_RDONLY) = 5
root@deb-test:~#

I've now used auditd to log the access:


----
time->Fri Jan 30 12:46:25 2026
type=PROCTITLE msg=audit(1769773585.832:436): proctitle="praliases"
type=PATH msg=audit(1769773585.832:436): item=0 name="/etc/mail/sendmail.cf" inode=784558 dev=fe:00 mode=0100644 ouid=0 ogid=104 rdev=00:00 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(1769773585.832:436): cwd="/root"
type=SYSCALL msg=audit(1769773585.832:436): arch=c000003e syscall=257 success=yes exit=3 a0=ffffffffffffff9c a1=560e85b91e6a a2=0 a3=0 items=1 ppid=4200 pid=4203 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=1 comm="praliases" exe="/usr/libexec/sendmail/praliases" subj=unconfined key="aliases"
----
time->Fri Jan 30 12:46:25 2026
type=PROCTITLE msg=audit(1769773585.836:437): proctitle="praliases"
type=PATH msg=audit(1769773585.836:437): item=0 name="/etc/mail/aliases.db" inode=783479 dev=fe:00 mode=0100644 ouid=101 ogid=104 rdev=00:00 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(1769773585.836:437): cwd="/root"
type=SYSCALL msg=audit(1769773585.836:437): arch=c000003e syscall=257 success=yes exit=4 a0=ffffffffffffff9c a1=7fff4dacd100 a2=0 a3=0 items=1 ppid=4200 pid=4203 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=1 comm="praliases" exe="/usr/libexec/sendmail/praliases" subj=unconfined key="aliases"
----
time->Fri Jan 30 12:46:25 2026
type=PROCTITLE msg=audit(1769773585.836:438): proctitle="praliases"
type=PATH msg=audit(1769773585.836:438): item=0 name="/etc/mail/aliases.db" inode=783479 dev=fe:00 mode=0100644 ouid=101 ogid=104 rdev=00:00 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(1769773585.836:438): cwd="/root"
type=SYSCALL msg=audit(1769773585.836:438): arch=c000003e syscall=257 success=yes exit=5 a0=ffffffffffffff9c a1=7fff4dace1f0 a2=0 a3=0
items=1 ppid=4200 pid=4203 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0
egid=0 sgid=0 fsgid=0 tty=pts1 ses=1 comm="praliases" exe="/usr/libexec/sendmail/praliases" subj=unconfined key="aliases"

Which lets me assume the access is being done by root.

root@deb-test:~# strace praliases 2>&1 |grep alias execve("/usr/sbin/praliases", ["praliases"], 0x7ffde3b673e0 /* 11 vars */) = 0 newfstatat(AT_FDCWD, "/etc/mail/aliases.db", {st_mode=S_IFREG|0640, st_size=2165, ...}, 0) = 0
newfstatat(AT_FDCWD, "/etc/mail/aliases.db", {st_mode=S_IFREG|0640, st_size=2165, ...}, 0) = 0
write(2, "praliases: /etc/mail/aliases: op"..., 54praliases: /etc/mail/aliases: open: Permission denied
root@deb-test:~#

What is the reason for that?

Which permissions does it want (I prefer only readable by the
daemon's users) and why?
--
kind regards
Marco

Send spam to 1769770110muell@stinkedores.dorfdsl.de

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.mail.sendmail

Marco Moock <mm@dorfdsl.de> writes:

I noticed that the praliases command only works if
/etc/mail/aliases.db is globally readable.

On Slackware, all my .db are root-only, but some of the files that make
them are world readable. Sendmail is using the .db files.

-rw-r--r-- 1 smmta smmsp 2165 30. Jan 12:17 /etc/mail/aliases.db

ls -l /etc/mail/{aliases,*.db}
-rw-r----- 1 root root 12288 Nov 15 2024 /etc/mail/access.db
-rw-r--r-- 1 root root 800 Oct 17 2023 /etc/mail/aliases
-rw-r----- 1 root root 12288 Oct 17 2023 /etc/mail/aliases.db
-rw-r----- 1 root root 12288 Mar 19 2022 /etc/mail/authinfo.db
-rw-r----- 1 root root 12288 Apr 14 2022 /etc/mail/domaintable.db
-rw-r----- 1 root root 12288 Apr 25 2024 /etc/mail/mailertable.db
-rw-r----- 1 root root 12288 Apr 25 2024 /etc/mail/uudomain.db
-rw-r----- 1 root root 12288 Jan 9 2018 /etc/mail/virtusertable.db

exe="/usr/libexec/sendmail/praliases" subj=unconfined key="aliases"

Sendmail in libexec? Debian sure does it weird.

type=SYSCALL msg=audit(1769773585.836:438): arch=c000003e syscall=257 success=yes exit=5 a0=ffffffffffffff9c a1=7fff4dace1f0 a2=0 a3=0
items=1 ppid=4200 pid=4203 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0
egid=0 sgid=0 fsgid=0 tty=pts1 ses=1 comm="praliases" exe="/usr/libexec/sendmail/praliases" subj=unconfined key="aliases"

Which lets me assume the access is being done by root.

root@deb-test:~# strace praliases 2>&1 |grep alias execve("/usr/sbin/praliases", ["praliases"], 0x7ffde3b673e0 /* 11 vars */) = 0
newfstatat(AT_FDCWD, "/etc/mail/aliases.db", {st_mode=S_IFREG|0640, st_size=2165, ...}, 0) = 0
newfstatat(AT_FDCWD, "/etc/mail/aliases.db", {st_mode=S_IFREG|0640, st_size=2165, ...}, 0) = 0
write(2, "praliases: /etc/mail/aliases: op"..., 54praliases: /etc/mail/aliases: open: Permission denied
root@deb-test:~#

What is the reason for that?

Is your praliases setuid/setgid to something? My user can't "praliases"
but root can.
--
PGP Key ID: 781C A3E2 C6ED 70A6 B356 7AF5 B510 542E D460 5CAE
"The Internet should always be the Wild West!"
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.mail.sendmail

On 30.01.2026 14:15 Uhr jayjwa wrote:

Marco Moock <mm@dorfdsl.de> writes:

I noticed that the praliases command only works if
/etc/mail/aliases.db is globally readable.

On Slackware, all my .db are root-only, but some of the files that
make them are world readable. Sendmail is using the .db files.

That is interesting. Can you show the ls -la of the files?

What happens if you remove the world readability?
IIRC sendmail can use text-only files without the DBs, can you check
with strace if it falls back to this?

-rw-r--r-- 1 smmta smmsp 2165 30. Jan 12:17 /etc/mail/aliases.db

ls -l /etc/mail/{aliases,*.db}
-rw-r----- 1 root root 12288 Nov 15 2024 /etc/mail/access.db
-rw-r--r-- 1 root root 800 Oct 17 2023 /etc/mail/aliases
-rw-r----- 1 root root 12288 Oct 17 2023 /etc/mail/aliases.db
-rw-r----- 1 root root 12288 Mar 19 2022 /etc/mail/authinfo.db
-rw-r----- 1 root root 12288 Apr 14 2022 /etc/mail/domaintable.db
-rw-r----- 1 root root 12288 Apr 25 2024 /etc/mail/mailertable.db
-rw-r----- 1 root root 12288 Apr 25 2024 /etc/mail/uudomain.db
-rw-r----- 1 root root 12288 Jan 9 2018 /etc/mail/virtusertable.db

exe="/usr/libexec/sendmail/praliases" subj=unconfined key="aliases"

Sendmail in libexec? Debian sure does it weird.

type=SYSCALL msg=audit(1769773585.836:438): arch=c000003e
syscall=257 success=yes exit=5 a0=ffffffffffffff9c a1=7fff4dace1f0
a2=0 a3=0 items=1 ppid=4200 pid=4203 auid=1000 uid=0 gid=0 euid=0
suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=1 comm="praliases" exe="/usr/libexec/sendmail/praliases" subj=unconfined key="aliases"

Which lets me assume the access is being done by root.

root@deb-test:~# strace praliases 2>&1 |grep alias execve("/usr/sbin/praliases", ["praliases"], 0x7ffde3b673e0 /* 11
vars */) = 0 newfstatat(AT_FDCWD, "/etc/mail/aliases.db", {st_mode=S_IFREG|0640, st_size=2165, ...}, 0) = 0
newfstatat(AT_FDCWD, "/etc/mail/aliases.db", {st_mode=S_IFREG|0640, st_size=2165, ...}, 0) = 0
write(2, "praliases: /etc/mail/aliases: op"..., 54praliases: /etc/mail/aliases: open: Permission denied
root@deb-test:~#

What is the reason for that?

Is your praliases setuid/setgid to something? My user can't
"praliases" but root can.

m@deb-test:~$ ls -la /usr/libexec/sendmail/praliases
-rwxr-xr-x 1 root root 99600 26. Okt 02:00 /usr/libexec/sendmail/praliases m@deb-test:~$ type /usr/libexec/sendmail/praliases /usr/libexec/sendmail/praliases ist /usr/libexec/sendmail/praliases m@deb-test:~$ file /usr/libexec/sendmail/praliases /usr/libexec/sendmail/praliases: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=affe96eda415a14edfb53fde6eb52a4ece2f9473, for GNU/Linux 3.2.0, stripped
m@deb-test:~$
--
kind regards
Marco

Send spam to 1769778923muell@stinkedores.dorfdsl.de

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.mail.sendmail

On Fri, 30 Jan 2026 12:51:50 +0100, Marco Moock wrote:

Hello!

I have a Debian unstable system to test.

I noticed that the praliases command only works if /etc/mail/aliases.db
is globally readable.

-rw-r--r-- 1 smmta smmsp 2165 30. Jan 12:17 /etc/mail/aliases.db

Can confirm it happens to me too.

I got a Debian system with 2 aliases files defined. "praliases" works on
the .db that is world-readable and fails on the 2nd .db that is not world- readable.


[working case:]

I now used strace to track that down:

This is when it works (world readable):

root@deb-test:~# ls -la /etc/mail/aliases.db -rw-r--r-- 1 smmta smmsp
2165 30. Jan 12:17 /etc/mail/aliases.db root@deb-test:~# strace
praliases 2>&1 |grep alias execve("/usr/sbin/praliases", ["praliases"], 0x7ffe430974f0 /* 11 vars */) = 0 newfstatat(AT_FDCWD, "/etc/mail/aliases.db", {st_mode=S_IFREG|0644, st_size=2165, ...}, 0) =
0 newfstatat(AT_FDCWD, "/etc/mail/aliases.db", {st_mode=S_IFREG|0644, st_size=2165, ...}, 0) = 0 openat(AT_FDCWD, "/etc/mail/aliases.db",
O_RDONLY) = 4 openat(AT_FDCWD, "/etc/mail/aliases.db", O_RDONLY) = 5 root@deb-test:~#

[non-working case:]

root@deb-test:~# strace praliases 2>&1 |grep alias execve("/usr/sbin/praliases", ["praliases"], 0x7ffde3b673e0 /* 11 vars
*/) = 0 newfstatat(AT_FDCWD, "/etc/mail/aliases.db",
{st_mode=S_IFREG|0640, st_size=2165, ...}, 0) = 0 newfstatat(AT_FDCWD, "/etc/mail/aliases.db", {st_mode=S_IFREG|0640, st_size=2165, ...}, 0) =
0 write(2, "praliases: /etc/mail/aliases: op"..., 54praliases: /etc/mail/aliases: open: Permission denied root@deb-test:~#

What is the reason for that?

Which permissions does it want (I prefer only readable by the daemon's
users) and why?

I think this is a case in which sendmail does more checks than the OS requires.

Experience says that root on *nix can read every file regardless of permissions (even files with mode 0). I'm with you with that but not
sendmail.

My "strace" shows things similar to you. "aliases.db" is "stat()" first
than "open()" when it works. But fails after "stat()" without "open()" in
the failing case.


I did not debug a running binary but from Sendmail's source code,
"safefile()" from "libsmutil/safefile.c" is called before opening a
database file.

That "safefile()" function can actually set errno=EACCESS if it doesn't
like something about the file permissions of a file.

Anyway, "safefile()" seems to really want the user/group of the running Sendmail program to have read access as one of the owner/group/other of
the target file. And checks against information returned by "stat()".



As a solution and I don't know if it breaks anything:

you can add "root" to the group "smmsp" in /etc/group to make "praliases" work.


Is adding a additional group to the "root" user is dangerous though? (It's actually quite common on BSD, but all my Debian derived Linux have no additional groups for root.)

I don't care enough about "praliases" to run a system in this
configuration for weeks to figure out potential issues.


Good luck, maybe others can chip in. Or may have beter understanding of
the Sendmail code.
--
Hugo Villeneuve-Lapointe
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.mail.sendmail

Marco Moock <mm@dorfdsl.de> writes:

That is interesting. Can you show the ls -la of the files?

ls -la /etc/mail
total 424
drwxr-xr-x 2 root root 4096 Dec 29 10:29 ./
drwxr-xr-x 162 root root 16384 Jan 28 10:41 ../
-rw-r--r-- 1 root root 4297 Nov 15 2024 access
-rw-r----- 1 root root 12288 Nov 15 2024 access.db
-rw-r--r-- 1 root root 800 Oct 17 2023 aliases
-rw-r----- 1 root root 12288 Oct 17 2023 aliases.db
-rw-r--r-- 1 root root 69465 Oct 29 12:34 atr2-smtp.cf
-r--r--r-- 1 root smmsp 5882 Apr 14 2022 atr2-smtp-client-cert.pem -r--r----- 1 root smmsp 1679 Apr 14 2022 atr2-smtp-client-key.pem -rw-r--r-- 1 root root 2422 Oct 29 12:33 atr2-smtp.m4
-r--r--r-- 1 root smmsp 5904 Apr 14 2022 atr2-smtp-srv-cert.pem
-r--r----- 1 root smmsp 1675 Apr 14 2022 atr2-smtp-srv-key.pem
-rw-r--r-- 1 root root 41917 Oct 29 11:14 atr2-submit.cf
-rw-r--r-- 1 root root 977 Oct 29 11:14 atr2-submit.m4
-rw-r----- 1 root root 113 Mar 19 2022 authinfo
-rw-r----- 1 root root 12288 Mar 19 2022 authinfo.db
lrwxrwxrwx 1 root root 22 Jan 5 2018 cf -> /usr/share/sendmail/cf/ -rw-r--r-- 1 root root 0 Jan 9 2018 domaintable
-rw-r----- 1 root root 12288 Apr 14 2022 domaintable.db
-rw-r--r-- 1 root root 5988 Dec 27 14:58 helpfile
-rw-r--r-- 1 root root 30 Aug 4 2023 local-host-names
-rw-r--r-- 1 root root 140 Apr 25 2024 mailertable
-rw-r----- 1 root root 12288 Apr 25 2024 mailertable.db
-rw-r--r-- 1 root root 644 Apr 14 2022 Makefile
-rw-r--r-- 1 root root 4095 Feb 23 2025 milter-regex.conf
-rw-r--r-- 1 root root 1 Nov 13 2017 relay-domains
lrwxrwxrwx 1 root root 12 May 14 2021 sendmail.cf -> atr2-smtp.cf -rw-r--r-- 1 root root 2425 Aug 31 2022 site.config.m4
-rw-r--r-- 1 root root 1448 Jan 31 09:28 statistics
lrwxrwxrwx 1 root root 14 May 14 2021 submit.cf -> atr2-submit.cf -rw-r--r-- 1 root root 11 Dec 19 2009 trusted-users
-rw-r--r-- 1 root root 48 Apr 25 2024 uudomain
-rw-r----- 1 root root 12288 Apr 25 2024 uudomain.db
-rw-r--r-- 1 root root 65630 Nov 2 2020 vdrl-smtp.cf
-rw-r--r-- 1 root root 2248 Nov 2 2020 vdrl-smtp.m4
-rw-r--r-- 1 root root 41329 Nov 2 2020 vdrl-submit.cf
-rw-r--r-- 1 root root 1306 Nov 2 2020 vdrl-submit.m4
-rw-r--r-- 1 root root 1 Jan 9 2018 virtusertable
-rw-r----- 1 root root 12288 Jan 9 2018 virtusertable.db

What happens if you remove the world readability?

Then only root reads it.

IIRC sendmail can use text-only files without the DBs, can you check
with strace if it falls back to this?

Maybe Sendmail can be built like that, but it won't use the plain text
files here.

mv aliases.db hide-aliases.db
root@atr2 /etc/mail # praliases
praliases: /etc/mail/aliases: open: Unknown database type

It's rather long, but here is the relavent part:

openat(AT_FDCWD, "/etc/mail/sendmail.cf", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=69465, ...}) = 0
read(3, "\n#\n# Copyright (c) 1998-2004, 20"..., 4096) = 4096
read(3, "C[[\n\n# access_db acceptance clas"..., 4096) = 4096 newfstatat(AT_FDCWD, "/etc/mail/aliases.db", 0x7fffffffaf00, 0) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/", {st_mode=S_IFDIR|0755, st_size=4096, ...}, AT_SYMLINK_NOFOLLOW) = 0
geteuid() = 0
newfstatat(AT_FDCWD, "/etc", {st_mode=S_IFDIR|0755, st_size=16384, ...}, AT_SYMLINK_NOFOLLOW) = 0
geteuid() = 0
newfstatat(AT_FDCWD, "/etc/mail", {st_mode=S_IFDIR|0755, st_size=4096, ...}, AT_SYMLINK_NOFOLLOW) = 0
geteuid() = 0
newfstatat(AT_FDCWD, "/etc/mail/aliases.db", 0x7fffffffaf00, 0) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/", {st_mode=S_IFDIR|0755, st_size=4096, ...}, AT_SYMLINK_NOFOLLOW) = 0
geteuid() = 0
newfstatat(AT_FDCWD, "/etc", {st_mode=S_IFDIR|0755, st_size=16384, ...}, AT_SYMLINK_NOFOLLOW) = 0
geteuid() = 0
newfstatat(AT_FDCWD, "/etc/mail", {st_mode=S_IFDIR|0755, st_size=4096, ...}, AT_SYMLINK_NOFOLLOW) = 0
geteuid() = 0
write(2, "praliases: /etc/mail/aliases: op"..., 58praliases: /etc/mail/aliases: open: Unknown database type
) = 58

m@deb-test:~$ ls -la /usr/libexec/sendmail/praliases
-rwxr-xr-x 1 root root 99600 26. Okt 02:00 /usr/libexec/sendmail/praliases

This is looking Debian-specific. What does the listener and the queue
runner run as? Here it's root and smmsp. Maybe Debian runs those as
something else. The running processes and the files it needs to read
must match up.

ls -l /usr/bin/praliases
-rwxr-xr-x 1 root root 91760 Dec 27 14:58 /usr/bin/praliases*
ls -l /usr/sbin/sendmail
-r-xr-sr-x 1 root smmsp 906560 Dec 27 14:58 /usr/sbin/sendmail*

Slackware's is like when I built Sendmail myself. Looks like Debian
moves things around and maybe adds users/changes permissions.
--
PGP Key ID: 781C A3E2 C6ED 70A6 B356 7AF5 B510 542E D460 5CAE
"The Internet should always be the Wild West!"
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.mail.sendmail

Hugo Villeneuve-Lapointe <hugo_villap@email.invalid> wrote:

Good luck, maybe others can chip in. Or may have beter understanding of
the Sendmail code.

Why not use LDAP for all the DBs and aliases? It is easy to set up and
avoids having to run makemap and praliases. File sendmail.schema just
has to be included in OpenLDAP. Probably works fine 389ds too.

Here is the LDAP related stuff in my sendmail configuration:

fbsd15:~ $ grep -i ldap /etc/mail/sendmail.mc define(`confLDAP_DEFAULT_SPEC',`-x -H ldap://fbsd15.local -w3 -b dc=fbsd15,dc=local -d cn=sendmail,dc=fbsd15,dc=local -M simple -P /etc/mail/ldap-secret -s sub')dnl
define(`confLDAP_CLUSTER', `mtacluster')dnl
define(`ALIAS_FILE', `ldap:')dnl
FEATURE(mailertable, `LDAP')dnl
FEATURE(`virtusertable', `LDAP')dnl
FEATURE(authinfo, `LDAP')dnl
FEATURE(genericstable, `LDAP')dnl

Instead of praliases, we can use a simple shell script like this:

fbsd15:~ $ cat /root/bin/sm_list_aliases
#!/usr/local/bin/bash

PROG=$(basename $0)

[ $# -eq 0 ] || { echo $PROG usage: $PROG; exit 1; }

ldapsearch -o ldif-wrap=no -LLL -x -D cn=root,dc=fbsd15,dc=local -w passwordhere -H ldap://fbsd15.local -b dc=fbsd15,dc=local -S sendmailMTAKey "(objectClass=sendmailMTAAliasObject)" sendmailMTAKey sendmailMTAAliasValue Description | egrep -v '^(dn:|#)' | sed '$d'

br,
KK
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.mail.sendmail

On 31.01.2026 19:28 Uhr Kalevi Kolttonen wrote:

Hugo Villeneuve-Lapointe <hugo_villap@email.invalid> wrote:

Good luck, maybe others can chip in. Or may have beter
understanding of the Sendmail code.

Why not use LDAP for all the DBs and aliases? It is easy to set up and
avoids having to run makemap and praliases. File sendmail.schema just
has to be included in OpenLDAP. Probably works fine 389ds too.

Because I am not familiar with that and have no need for it. The
aliases will be updated when needed by me.
--
kind regards
Marco

Send spam to 1769884096muell@stinkedores.dorfdsl.de

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.mail.sendmail

On 31.01.2026 11:26 Uhr jayjwa wrote:

This is looking Debian-specific. What does the listener and the queue
runner run as?

Daemon is running as root.
--
kind regards
Marco

Send spam to 1769855191muell@stinkedores.dorfdsl.de

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.mail.sendmail

On Sat, 31 Jan 2026 22:10:12 +0100, Marco Moock wrote:

On 31.01.2026 11:26 Uhr jayjwa wrote:

This is looking Debian-specific. What does the listener and the queue
runner run as?

Daemon is running as root.

Yeah, It looks to be Debian-specific.

# egrep "RunAsUser|TrustedUser" *.cf
sendmail.cf:#O RunAsUser=sendmail
sendmail.cf:O TrustedUser=smmta
submit.cf:O RunAsUser=smmsp
submit.cf:O TrustedUser=smmsp

Debian is happy to run the daemon as root but enforce files to be owned by "smmta". This is why the ownership of files in /etc/mail is more complex
than other installations.

(Mind you, Debian have been doing more than a decade by now. Just not a
lot of folks using sendmail or praliases with a non-public readable
aliases.db I guess.)


OpenBSD package sendmail with RunAsUser and TrustedUser commented in sendmail.cf. So files in /etc/mail are happily owned by root and it works.

Slackware 15 (released 2024-07) is now using Postfix as default MTA. But
the sendmail in "extras" is still like that (no TrustedUser option for the daemon).

Others I don't know.
--
Hugo Villeneuve-Lapointe
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.mail.sendmail

On Sat, 31 Jan 2026 14:29:56 -0000 (UTC), Hugo Villeneuve-Lapointe wrote:

My "strace" shows things similar to you. "aliases.db" is "stat()" first
than "open()" when it works. But fails after "stat()" without "open()"
in the failing case.

I did not debug a running binary but from Sendmail's source code, "safefile()" from "libsmutil/safefile.c" is called before opening a
database file.

That "safefile()" function can actually set errno=EACCESS if it doesn't
like something about the file permissions of a file.

Anyway, "safefile()" seems to really want the user/group of the running Sendmail program to have read access as one of the owner/group/other of
the target file. And checks against information returned by "stat()".

I missed the part that safefile() is affected by "O TrustedUser". So
that's added to the mix in Debian's sendmail.

(How affected? I don't know, but safefile() is 315 lines long so my effort will be limited.)
--
Hugo Villeneuve-Lapointe
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.mail.sendmail

Marco Moock <mm@dorfdsl.de> wrote:

On 31.01.2026 19:28 Uhr Kalevi Kolttonen wrote:

Hugo Villeneuve-Lapointe <hugo_villap@email.invalid> wrote:

Good luck, maybe others can chip in. Or may have beter
understanding of the Sendmail code.

Why not use LDAP for all the DBs and aliases? It is easy to set up and
avoids having to run makemap and praliases. File sendmail.schema just
has to be included in OpenLDAP. Probably works fine 389ds too.

Because I am not familiar with that and have no need for it. The
aliases will be updated when needed by me.

Okay. I got tired of BerkeleyBD/OracleDB/whatever issues and migrated everything to OpenLDAP. I have simple shell scripts to create, add and
delete aliases. I will show them here in case someone else is interested
in LDAP + Sendmail integration:

fbsd15:~ $ cat /root/bin/sm_add_alias
#!/usr/local/bin/bash

PROG=$(basename $0)

[ $# -eq 2 ] || { echo "$PROG usage: $PROG alias value"; exit 1; }

KEY=$1
VALUE=$2

ldapadd -x -D cn=root,dc=fbsd15,dc=local -w pw -H ldap://fbsd15.local -f <(cat <<EOF
dn: sendmailMTAKey=$KEY,dc=fbsd15,dc=local
objectClass: sendmailMTA
objectClass: sendmailMTAAlias
objectClass: sendmailMTAAliasObject
sendmailMTAAliasGrouping: aliases
sendmailMTACluster: mtacluster
sendmailMTAKey: $KEY
sendmailMTAAliasValue: $VALUE
description: foo
EOF
)


fbsd15:~ $ cat /root/bin/sm_add_alias_value
#!/usr/local/bin/bash

PROG=$(basename $0)

[ $# -eq 2 ] || { echo $PROG usage: $PROG alias value; exit 1; }

ALIAS=$1
VALUE=$2

ldapmodify -ZZ -D cn=root,dc=fbsd15,dc=local -w pw -h fbsd15.local -f <(cat <<EOF
dn: sendmailMTAKey=$ALIAS,dc=fbsd15,dc=local
changetype: modify
add: sendmailMTAAliasValue
sendmailMTAAliasValue: $VALUE
EOF
)

fbsd15:~ $ cat /root/bin/sm_delete_alias
#!/usr/local/bin/bash

PROG=$(basename $0)

[ $# -eq 1 ] || { echo $PROG usage: $PROG alias; exit 1; }

ALIAS=$1

ldapdelete -x -H ldap://fbsd15.local -w3 -D cn=root,dc=fbsd15,dc=local -w pw sendmailMTAKey=$ALIAS,dc=fbsd15,dc=local

br,
KK
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.mail.sendmail

Kalevi Kolttonen <kalevi@kolttonen.fi> wrote:

fbsd15:~ $ cat /root/bin/sm_add_alias_value
...
ldapmodify -ZZ -D cn=root,dc=fbsd15,dc=local -w pw -h fbsd15.local -f <(cat <<EOF

Sorry, my scripts were migrated from Red Hat Enterprise
Linux 7 where I had proper TLS support in OpenLDAP. Now on
my FreeBSD 15 server I did not bother to set up TLS
so the -ZZ seen above does not work there.

I have to fix this script.

br,
KK
--- Synchronet 3.21b-Linux NewsLink 1.2