set-permissions fails: how to fix and/or manual set correct permissions?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

set-permissions fails: how to fix and/or manual set correct permissions?

Max Mustermann
platform: Entware (OpenWRT based = router firmware)
-> minimal: no SElinux, no appArmor, readme_directory = no, etc.

environment: root user name is renamed
# postconf -n
command_directory = /opt/sbin
compatibility_level = 2
config_directory = /opt/etc/postfix
daemon_directory = /opt/libexec/postfix
data_directory = /opt/var/lib/postfix
debug_peer_level = 2
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd
$daemon_directory/$process_name $process_id & sleep 5
default_database_type = cdb
inet_protocols = ipv4
mail_spool_directory = /opt/var/mail
manpage_directory = no
myhostname = domain.nl
mynetworks = 1.1.2.1,8.9.1.1
queue_directory = /opt/var/spool/postfix
shlib_directory = /opt/lib/postfix
smtputf8_enable = no
unknown_local_recipient_reject_code = 550

# postfix set-permissions
find: unknown user root

# ls -lah /opt/sbin/postdrop
-rwxr-xr-x    1 NewRootUser   root      246.8K

Trying to manually fix permissions:
# chown AdminUserName:postdrop /opt/sbin/postdrop
# chown AdminUserName:postdrop /opt/sbin/postqueue
# chmod g+s /opt/sbin/postdrop
# chmod g+s /opt/sbin/postqueue

Result:
# postfix -vvvv start
...
postfix: dict_lookup: html_directory = no
postfix: mac_parse: no
postfix: dict_eval: const  no
postsuper: fatal: scan_dir_push: open directory defer: Permission denied

#  ls -la /opt/var/spool/postfix
drwxr-xr-x   16 AdminUserName   root          4096 Sep 22 23:53 .
drwxr-xr-x    3 AdminUserName   root          4096 Sep 22 23:53 ..
drwx------    2 AdminUserName   root          4096 Sep  8 22:33 active
drwx------    2 AdminUserName   root          4096 Sep  8 22:33 bounce
drwx------    2 AdminUserName   root          4096 Sep  8 22:33 corrupt
drwx------    2 AdminUserName   root          4096 Sep  8 22:33 defer
drwx------    2 AdminUserName   root          4096 Sep  8 22:33 deferred
drwx------    2 AdminUserName   root          4096 Sep  8 22:33 flush
drwx------    2 AdminUserName   root          4096 Sep  8 22:33 hold
drwx------    2 AdminUserName   root          4096 Sep  8 22:33 incoming
drwx-wx---    2 AdminUserName   root          4096 Sep  8 22:33 maildrop
drwxr-xr-x    2 AdminUserName   root          4096 Sep  8 22:33 pid
drwx------    2 AdminUserName   root          4096 Sep  8 22:33 private
drwx--x---    2 AdminUserName   root          4096 Sep  8 22:33 public
drwx------    2 AdminUserName   root          4096 Sep  8 22:33 saved
drwx------    2 AdminUserName   root          4096 Sep  8 22:33 trace

Note: all above directories have read and execute permission for
everyone (.......r-x)

1. How to make "postfix set-permissions" learn how to correctly set the
required permissions?

2. How to manually fix the postfix permissions?
Reply | Threaded
Open this post in threaded view
|

Re: set-permissions fails: how to fix and/or manual set correct permissions?

Wietse Venema
Max Mustermann:
> # postfix set-permissions
> find: unknown user root

WTF?

> # ls -lah /opt/sbin/postdrop
> -rwxr-xr-x    1 NewRootUser   root      246.8K

Postfix requires a standard environment, with a user called "root"
who has super-user privileges, with UID zero and GID zero. I don't
expect that she needs to have a 'login shell', but I don't have the
time to verify that.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: set-permissions fails: how to fix and/or manual set correct permissions?

Max Mustermann
How should I know that postfix requires the super-user to have "root" as
name?

I don't see this information in the README, neither in the (file system)
requirements.

Or can't I read?


On 30-09-18 18:24, Wietse Venema wrote:

> Max Mustermann:
>> # postfix set-permissions
>> find: unknown user root
>
> WTF?
>
>> # ls -lah /opt/sbin/postdrop
>> -rwxr-xr-x    1 NewRootUser   root      246.8K
>
> Postfix requires a standard environment, with a user called "root"
> who has super-user privileges, with UID zero and GID zero. I don't
> expect that she needs to have a 'login shell', but I don't have the
> time to verify that.
>
> Wietse
>
Reply | Threaded
Open this post in threaded view
|

Re: set-permissions fails: how to fix and/or manual set correct permissions?

Viktor Dukhovni
> On Sep 30, 2018, at 1:26 PM, Max Mustermann <[hidden email]> wrote:
>
> How should I know that postfix requires the super-user to have "root" as name?
>
> I don't see this information in the README, neither in the (file system) requirements.

Some assumptions are inevitably so basic that they're not written down.
You won't find documentation of the need for a Bourne-shell executable
in "/bin/sh", a "find" with a standard interface on your PATH, ...

Postfix documentation is not the POSIX specification.  On systems that
deviate from longstanding standard practice, the administrator can
expect some friction due to violated assumptions.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: set-permissions fails: how to fix and/or manual set correct permissions?

Max Mustermann
Usually it's a mistake to test if the user is root.
POSIX does not even require a root user.

source:
<https://stackoverflow.com/questions/4159910/check-if-user-is-root-in-c>



On 30-09-18 19:36, Viktor Dukhovni wrote:
> Postfix documentation is not the POSIX specification.  On systems that
> deviate from longstanding standard practice, the administrator can
> expect some friction due to violated assumptions.
Reply | Threaded
Open this post in threaded view
|

Re: set-permissions fails: how to fix and/or manual set correct permissions?

Viktor Dukhovni
> On Sep 30, 2018, at 2:51 PM, Max Mustermann <[hidden email]> wrote:
>
> Usually it's a mistake to test if the user is root.
> POSIX does not even require a root user.

This is not a productive discussion...  The Postfix deployment
scripts reasonably expect to be able to chown files to "root",
or check whether they belong to "root".  That is they expect
a reasonably standard Unix system.  No further comment.

--
        Viktor.