Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.mail.sendmail > #8234 > unrolled thread

praliases file permission check

Back to article view | Back to comp.mail.sendmail

Contents

  praliases file permission check Marco Moock <mm@dorfdsl.de> - 2026-01-30 12:51 +0100
    Re: praliases file permission check jayjwa <jayjwa@atr2.ath.cx.invalid> - 2026-01-30 14:15 -0500
      Re: praliases file permission check Marco Moock <mm@dorfdsl.de> - 2026-01-30 20:53 +0100
        Re: praliases file permission check jayjwa <jayjwa@atr2.ath.cx.invalid> - 2026-01-31 11:26 -0500
          Re: praliases file permission check Marco Moock <mm@dorfdsl.de> - 2026-01-31 22:10 +0100
            Re: praliases file permission check Hugo Villeneuve-Lapointe <hugo_villap@email.invalid> - 2026-01-31 22:42 +0000
    Re: praliases file permission check Hugo Villeneuve-Lapointe <hugo_villap@email.invalid> - 2026-01-31 14:29 +0000
      Re: praliases file permission check kalevi@kolttonen.fi (Kalevi Kolttonen) - 2026-01-31 19:28 +0000
        Re: praliases file permission check Marco Moock <mm@dorfdsl.de> - 2026-01-31 22:06 +0100
          Re: praliases file permission check kalevi@kolttonen.fi (Kalevi Kolttonen) - 2026-01-31 23:24 +0000
            Re: praliases file permission check kalevi@kolttonen.fi (Kalevi Kolttonen) - 2026-01-31 23:30 +0000
      Re: praliases file permission check Hugo Villeneuve-Lapointe <hugo_villap@email.invalid> - 2026-01-31 22:55 +0000

#8234 — praliases file permission check

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

[toc] | [next] | [standalone]

#8235

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!"

[toc] | [prev] | [next] | [standalone]

#8236

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

[toc] | [prev] | [next] | [standalone]

#8238

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!"

[toc] | [prev] | [next] | [standalone]

#8241

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

[toc] | [prev] | [next] | [standalone]

#8242

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

[toc] | [prev] | [next] | [standalone]

#8237

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

[toc] | [prev] | [next] | [standalone]

#8239

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

[toc] | [prev] | [next] | [standalone]

#8240

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

[toc] | [prev] | [next] | [standalone]

#8244

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

[toc] | [prev] | [next] | [standalone]

#8245

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

[toc] | [prev] | [next] | [standalone]

#8243

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.mail.sendmail

csiph-web