Debian Bug report logs - #896879
[chroot] postfix: race condition on cp in /etc/network/if-*.d/postfix scripts

Reply or subscribe to this bug.

Display info messages

Message #5 received at [email protected] (full text, mbox, reply):

From: Vincent Lefevre <[email protected]>

To: Debian Bug Tracking System <[email protected]>

Subject: postfix: race condition on cp in /etc/network/if-*.d/postfix scripts

Date: Wed, 25 Apr 2018 11:20:40 +0200

Package: postfix
Version: 3.3.0-1
Severity: important
Tags: security

The /etc/network/if-*.d/postfix scripts contain:

if [ ! -x /sbin/resolvconf ]; then
        f=/etc/resolv.conf
        if ! cp $f $(postconf -hx queue_directory)$f 2>/dev/null; then
                exit 0
        fi

If two such scripts run concurrently (which is now possible), the two
"cp" commands can also run concurrently, with unexpected results on
the generated resolv.conf file for postfix.

It might be a security issue as a consequence is that an incorrect
DNS server could be used.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.15.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages postfix depends on:
ii  adduser                3.117
ii  cpio                   2.12+dfsg-6
ii  debconf [debconf-2.0]  1.5.66
ii  dpkg                   1.19.0.5
ii  e2fsprogs              1.44.1-2
ii  libc6                  2.27-3
ii  libdb5.3               5.3.28-13.1+b1
ii  libicu57               57.1-9
ii  libsasl2-2             2.1.27~101-g0780600+dfsg-3.1
ii  libssl1.1              1.1.0h-2
ii  lsb-base               9.20170808
ii  netbase                5.4
ii  ssl-cert               1.0.39

Versions of packages postfix recommends:
ii  python3  3.6.5-3

Versions of packages postfix suggests:
ii  bsd-mailx [mail-reader]  8.1.2-0.20160123cvs-4
pn  dovecot-common           <none>
ii  emacs25 [mail-reader]    25.2+1-6+b1
ii  libsasl2-modules         2.1.27~101-g0780600+dfsg-3.1
ii  mutt [mail-reader]       1.9.5-2
pn  postfix-cdb              <none>
ii  postfix-doc              3.3.0-1
pn  postfix-ldap             <none>
pn  postfix-lmdb             <none>
pn  postfix-mysql            <none>
ii  postfix-pcre             3.3.0-1
pn  postfix-pgsql            <none>
ii  postfix-sqlite           3.3.0-1
ii  procmail                 3.22-26
pn  resolvconf               <none>
pn  sasl2-bin                <none>
pn  ufw                      <none>

-- debconf information excluded

Message #16 received at [email protected] (full text, mbox, reply):

From: Michael Tokarev <[email protected]>

To: [email protected]

Subject: Re: Bug#896879: postfix: race condition on cp in /etc/network/if-*.d/postfix scripts

Date: Wed, 4 Dec 2024 19:46:53 +0300

Control: retitle -1 [chroot] postfix: race condition on cp in /etc/network/if-*.d/postfix scripts
Control: tag -1 - confirmed security + moreinfo

On Wed, 25 Apr 2018 11:20:40 +0200 Vincent Lefevre <[email protected]> wrote:
> Package: postfix
> Version: 3.3.0-1
> Severity: important
> Tags: security
> 
> The /etc/network/if-*.d/postfix scripts contain:
> 
> if [ ! -x /sbin/resolvconf ]; then
>         f=/etc/resolv.conf
>         if ! cp $f $(postconf -hx queue_directory)$f 2>/dev/null; then
>                 exit 0
>         fi
> 
> If two such scripts run concurrently (which is now possible), the two
> "cp" commands can also run concurrently, with unexpected results on
> the generated resolv.conf file for postfix.

Which unexpected result do you see might occur here?

cp(1) does open(O_TRUNC), write(), close().  The write() will write at
the current file position, - not appending.  When two concurrently run
cp(1) processes write it at the same time, the result will be the same,
since the content they're writing will be the same too.  So basically,
even if 10 concurrent cp(1) processes are writing at the same time, the
result will be the same resolv.conf in the chroot.

> It might be a security issue as a consequence is that an incorrect
> DNS server could be used.

I don't see it as a security issue, per se.

Thanks,

/mjt

Message #27 received at [email protected] (full text, mbox, reply):

From: Vincent Lefevre <[email protected]>

To: Michael Tokarev <[email protected]>, [email protected]

Subject: Re: Bug#896879: postfix: race condition on cp in /etc/network/if-*.d/postfix scripts

Date: Wed, 4 Dec 2024 22:44:08 +0100

On 2024-12-04 19:46:53 +0300, Michael Tokarev wrote:
> cp(1) does open(O_TRUNC), write(), close().

AFAIK, there is no guarantee that cp(1) does a single write():

https://pubs.opengroup.org/onlinepubs/9799919799/utilities/cp.html

This is not documented in the cp(1) man page from the GNU coreutils
either.

-- 
Vincent Lefèvre <[email protected]> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Message #32 received at [email protected] (full text, mbox, reply):

From: Michael Tokarev <[email protected]>

To: Vincent Lefevre <[email protected]>, [email protected]

Subject: Re: Bug#896879: postfix: race condition on cp in /etc/network/if-*.d/postfix scripts

Date: Thu, 5 Dec 2024 01:17:45 +0300

05.12.2024 00:44, Vincent Lefevre wrote:
> On 2024-12-04 19:46:53 +0300, Michael Tokarev wrote:
>> cp(1) does open(O_TRUNC), write(), close().
> 
> AFAIK, there is no guarantee that cp(1) does a single write():
Again, it does not matter.  Even if cp will write one byte at a
time, all of them will write identical content anyway.  Collectively
overriding file with the same bytes.

/mjt

Message #37 received at [email protected] (full text, mbox, reply):

From: Vincent Lefevre <[email protected]>

To: Michael Tokarev <[email protected]>

Cc: [email protected]

Subject: Re: Bug#896879: postfix: race condition on cp in /etc/network/if-*.d/postfix scripts

Date: Thu, 5 Dec 2024 00:05:18 +0100

On 2024-12-05 01:17:45 +0300, Michael Tokarev wrote:
> 05.12.2024 00:44, Vincent Lefevre wrote:
> > On 2024-12-04 19:46:53 +0300, Michael Tokarev wrote:
> > > cp(1) does open(O_TRUNC), write(), close().
> > 
> > AFAIK, there is no guarantee that cp(1) does a single write():
> Again, it does not matter.  Even if cp will write one byte at a
> time, all of them will write identical content anyway.  Collectively
> overriding file with the same bytes.

OK, but I'm still a bit uncomfortable with the fact that the
implementation of cp is not specified (at least some missing
guarantee that several cp's of the same file to the same target
is OK). In the past, I had bad surprised with concurrent writes,
but this could have been more complex cases (in my archives I can
only find an issue with the zsh history, but truncate operations
were also involved).

BTW, I'm wondering whether when a second interface is brought up,
/etc/resolv.conf could be modified, which would also be a problem.

-- 
Vincent Lefèvre <[email protected]> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Message #42 received at [email protected] (full text, mbox, reply):

From: Michael Tokarev <[email protected]>

To: Vincent Lefevre <[email protected]>, [email protected]

Subject: Re: Bug#896879: postfix: race condition on cp in /etc/network/if-*.d/postfix scripts

Date: Thu, 5 Dec 2024 04:03:12 +0300

05.12.2024 02:05, Vincent Lefevre wrote:

> OK, but I'm still a bit uncomfortable with the fact that the
> implementation of cp is not specified (at least some missing
> guarantee that several cp's of the same file to the same target
> is OK). In the past, I had bad surprised with concurrent writes,
> but this could have been more complex cases (in my archives I can
> only find an issue with the zsh history, but truncate operations
> were also involved).

it's definitely a more complex case. There's no way you can get
different result by running multiple `cp a b` in parallel, -
they will be writing the same data to the same places, with the
end result being the same.

> BTW, I'm wondering whether when a second interface is brought up,
> /etc/resolv.conf could be modified, which would also be a problem.
That could happen to, in some theory.  It's now a question how
resolv.conf itself is updated - here, it is much more important
to guard against multiple updates from DIFFERENT destinations.
So if things are running in parallel there, there's a much more
serious bug somewhere.

Anyway.

Today, with big shift from /etc/network/interfaces towards
systemd-networkd or network-manager, so parallel execution
of things managed by if-up.d/ et al becomes significantly
less probable, I'm not going to spend more time on this.

Also, a good advise here is to not run postfix chrooted to
begin with, as upstream pleaded for decades.

So I don't really see a point anymore.

Thanks,

/mjt

Send a report that this bug log contains spam.