Debian Bug report logs - #21941
dpkg: Scripts under /var prevent mounting /var with noexec

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: <slapic@orion.fido.hu>

To: submit@bugs.debian.org

Subject: dpkg: dpkg places it's pre-/post install/rm scripts under /var, which is mounted with noexec on most of the systems

Date: Thu, 30 Apr 1998 23:16:16 +0200 (CEST)

Package: dpkg
Version: 1.4.0.21

A common security configuration is to mount /tmp, /var with noexec option.
In this case, dpkg fails to install or remove anything.
One solution could be to remount /var with exec for the time of
upgrade/install/remove, but when dpkg has placed the script, it won't get
execution permissions until someone unpacks it again to there.

I suggest to put the scripts under /usr (/usr/lib/dpkg?) where all
executables should go.

-- System Information
Debian Release: 2.0 (unstable)
Kernel Version: Linux orion 2.1.98 #2 SMP Wed Apr 29 19:13:42 CEST 1998 i586 unknown

Versions of the packages dpkg depends on:
libc6	Version: 2.0.7pre1-4
libg++272	Version: 2.7.2.8-0.1
ncurses3.4	Version: 1.9.9g-8

Message #18 received at 21941@bugs.debian.org (full text, mbox, reply):

From: Andreas Barth <aba@not.so.argh.org>

To: 21941@bugs.debian.org

Subject: dpkg usage of /var

Date: Sun, 26 Dec 2010 16:56:49 +0100

Hi,

as we had just a discussion about this bug report on IRC, AFAICS there
are a couple of reasons and possibilities:

re usage of /var:
~~~~~~~~~~~~~~~~
dpkg puts the package data into /var/lib/dpkg/info. This includes the
list of files, the list of conffiles, templates, md5sums and also the
maintainer scripts of each package.

According to FHS:
| /var contains variable data files. This includes spool directories and
| files, administrative and logging data, and transient and temporary
| files.
re /var/lib:
| This hierarchy holds state information pertaining to an application or
| the system.

The usage of /var/lib/dpkg matches that description IMHO.



possible ways for /var to be no-exec
====================================

per local admin

1. use a different place via local configuration
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Technically, adding admindir=/some/other/place to /etc/dpkg/dpkg.cfg
(and an appropriate Dir::State::status to apts configuration) should
work. Any sysadmin can do that on his own system.


2. make /var/lib/dpkg/info an own mountpoint
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Either create a new partition, or re-mount the existing partition with
some mount --bind /var/lib/dpkg/info /var/lib/dpkg/info; mount
/var/lib/dpkg/info -o exec - you might call that ugly but it works.



per changes to dpkg

3. copy scripts around if necessary
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Most maintainer scripts are sh/bash/dash/perl-scripts. These can be
executed even if noexec is in place by explicit call via /bin/sh (or
whatever) -- basically an re-implementation of kernel code. Not nice
but would work. All other "scripts" would need to be copied somewhere
else prior execution (and I think it's sensible to disallow binary
maintainer scripts except for very few packages, including e.g. bash
itself).

4. remount /var with exec
~~~~~~~~~~~~~~~~~~~~~~~~~
AFAICS there is no option within dpkg (or not documented) to always
execute commands prior to an dpkg "writing" invocation (while there is
within apt). It might make sense to remount /var with exec in case
it's noexec before running any scripts.


I think adding hooks for dpkg to run scripts pre-/post-changing
requests (e.g. configure, remove, install, ...) might make sense.

Of course, there are a couple of more options like e.g. changing the
location on new installs, but as said, I consider the current place to
be the correct one according to FHS.


Andi

Message #23 received at 21941@bugs.debian.org (full text, mbox, reply):

From: Goswin von Brederlow <goswin-v-b@web.de>

To: 21941@bugs.debian.org

Cc: Andreas Barth <aba@not.so.argh.org>

Subject: Re: dpkg usage of /var

Date: Sun, 26 Dec 2010 17:57:07 +0100

Hi,

Andreas Barth <aba@not.so.argh.org> wrote:

> re usage of /var:
> ~~~~~~~~~~~~~~
> dpkg puts the package data into /var/lib/dpkg/info. This includes the
> list of files, the list of conffiles, templates, md5sums and also the
> maintainer scripts of each package.
> 
> According to FHS:
> | /var contains variable data files. This includes spool directories and
> | files, administrative and logging data, and transient and temporary
> | files.
> re /var/lib:
> | This hierarchy holds state information pertaining to an application or
> | the system.
> 
> The usage of /var/lib/dpkg matches that description IMHO.

I have to somewhat disagree there. The maintainer scripts are neigther
variable nor data. They are not-changing executables. One thing that one
could point to though is

| /var/lib : Variable state information
| ...
| /var/lib/<name> is the location that must be used for all distribution
| packaging support. Different distributions may use different names, of
| course.

On the other hand the FHS says:

| /usr/lib : Libraries for programming and packages
|
| Purpose
|
| /usr/lib includes object files, libraries, and internal binaries that
| are not intended to be executed directly by users or shell scripts. [22]
|
| Applications may use a single subdirectory under /usr/lib. If an
| application uses a subdirectory, all architecture-dependent data
| exclusively used by the application must be placed within that
| subdirectory. [23]

The maintainer scripts are "internal binaries that are not intended to
be executed directly by users or shell scripts". So /usr/lib/dpkg/ would
be a valid place to put them.


And I believe the possible argument that /usr is read-only so dpkg may
not write scripts there is not valid. The FHS says for example:

| /var is specified here in order to make it possible to mount /usr
| read-only. Everything that once went into /usr that is written to during
| system operation (as opposed to installation and software maintenance)
| must be in /var.

Clearly it already exempts unpack, install, remove and purge operations
from the restriction from not to write to usr. And dpkg writes/deletes
files in /usr anyway during those operations.


What would prevent storing the maintainer scripts in /usr other than
someone having to write the patch for it?

MfG
        Goswin

Message #28 received at 21941@bugs.debian.org (full text, mbox, reply):

From: Guillem Jover <guillem@debian.org>

To: Andreas Barth <aba@not.so.argh.org>, 21941@bugs.debian.org

Cc: Goswin von Brederlow <goswin-v-b@web.de>

Subject: Re: Bug#21941: dpkg usage of /var

Date: Wed, 5 Jan 2011 08:26:00 +0100

tag 21941 wontfix
thanks

[ Goswin, removing the wontfix tag is not something for you to decide. ]

On Sun, 2010-12-26 at 16:56:49 +0100, Andreas Barth wrote:
> re usage of /var:
> ~~~~~~~~~~~~~~~~
> dpkg puts the package data into /var/lib/dpkg/info. This includes the
> list of files, the list of conffiles, templates, md5sums and also the
> maintainer scripts of each package.
> 
> According to FHS:
> | /var contains variable data files. This includes spool directories and
> | files, administrative and logging data, and transient and temporary
> | files.
> re /var/lib:
> | This hierarchy holds state information pertaining to an application or
> | the system.
> 
> The usage of /var/lib/dpkg matches that description IMHO.

... as those files are clearly state for dpkg. Those scripts are variable
in the sense that they might appear, disappear, or change during a dpkg
run. So the location seems perfectly fine to me.

It's more relevant though the snippet Goswin pasted:

| /var/lib/<name> is the location that must be used for all distribution
| packaging support. Different distributions may use different names, of
| course.

The same equivalent path rpm is using for example. And thus I don't see
the point in changing the current location.

Even if the /usr/lib location could be interpreted and argued as valid
too, I'd not see the point in changing it, given the coding and
transition work involved, susceptible to system breakage, and
unfortunately also because there are programs out there which rely on
those paths (which could be solved with symlinks, but then we'd be
getting into really ugly territory, for no really good reason). But
mostly given the solution below.

> possible ways for /var to be no-exec
> ====================================

[...]

> per local admin

> 4. remount /var with exec
> ~~~~~~~~~~~~~~~~~~~~~~~~~
> AFAICS there is no option within dpkg (or not documented) to always
> execute commands prior to an dpkg "writing" invocation (while there is
> within apt). It might make sense to remount /var with exec in case
> it's noexec before running any scripts.

> I think adding hooks for dpkg to run scripts pre-/post-changing
> requests (e.g. configure, remove, install, ...) might make sense.

There's already the invoke hooks (see man dpkg), present since 1.15.4,
which allow just that.

thanks,
guillem

Message #35 received at 21941@bugs.debian.org (full text, mbox, reply):

From: Andreas Barth <aba@not.so.argh.org>

To: Guillem Jover <guillem@debian.org>

Cc: 21941@bugs.debian.org

Subject: Re: Bug#21941: dpkg usage of /var

Date: Wed, 5 Jan 2011 11:36:16 +0100

* Guillem Jover (guillem@debian.org) [110105 08:32]:
> On Sun, 2010-12-26 at 16:56:49 +0100, Andreas Barth wrote:
> > I think adding hooks for dpkg to run scripts pre-/post-changing
> > requests (e.g. configure, remove, install, ...) might make sense.
> 
> There's already the invoke hooks (see man dpkg), present since 1.15.4,
> which allow just that.

Right, reading the man page on an testing / unstable system has
advantages.

I'd suggest to document the proper procedure for "var as noexec" in an
README-file. Of course, anyone can provide the proper documentation in
this bug report first (all the pieces are there), so you could pick it
up from there.



Andi

Message #40 received at 21941@bugs.debian.org (full text, mbox, reply):

From: Goswin von Brederlow <goswin-v-b@web.de>

To: 21941@bugs.debian.org

Cc: <aba@not.so.argh.org>, Andreas@book.localnet, Barth@book.localnet

Subject: Re: Bug#21941: dpkg usage of /var

Date: Wed, 12 Jan 2011 08:32:59 +0100

Hi,

Guillem Jover <guillem@debian.org> wrote:
> Even if the /usr/lib location could be interpreted and argued as valid
> too, I'd not see the point in changing it, given the coding and
> transition work involved, susceptible to system breakage, and
> unfortunately also because there are programs out there which rely on
> those paths (which could be solved with symlinks, but then we'd be
> getting into really ugly territory, for no really good reason). But
> mostly given the solution below.

The location of those script must change for multiarch because they are not
unique enough in the face of the same package being installed from multiple
architectures.

I know that is not an argument why the location should be changed but since
we do need to change them anyway we might as well consider changing them
more.

MfG
	Goswin

PS: With the hooks there is now a solution for this bug and a valid reason for 
wontfix. If someone documents this some more, e.g. write example hooks, it
could even be closed.

Message #45 received at 21941@bugs.debian.org (full text, mbox, reply):

From: Trek <trek00@inbox.ru>

To: 21941@bugs.debian.org

Subject: Re: Bug#21941: dpkg usage of /var

Date: Sun, 15 Feb 2015 23:23:15 +0100

here the example hooks for readonly /usr and noexec /var that should be
added to /etc/apt/apt.conf to works with apt-get/aptitude:

DPkg {
    // Auto re-mounting of a readonly /usr and noexec /var
    Pre-Invoke { "mount -o remount,rw /usr && mount -o remount,exec /var"; };
    Post-Invoke { "test ${NO_APT_REMOUNT:-no} = yes || mount -o remount,ro /usr && mount -o remount,noexec /var || true"; };
};


this is slightly modified from the debian wiki:

https://wiki.debian.org/ReadonlyRoot#Make_apt-get_remount_.2F_if_needed

ciao

Message #52 received at 21941@bugs.debian.org (full text, mbox, reply):

From: PLS Tech <plst232@gmail.com>

To: 20stationfire baer <20stationfire.baer@gmail.com>, 20teesseopatel <20teesseopatel@hotmail.com>, 2173 83925jgamers <2173.83925jgamers@t-online.de>, 218 4 ever <218_4_ever@gmx.de>, 21941 <21941@bugs.debian.org>, 21stories <21stories@gmx.at>

Subject: Re:ONLINE NOTIFICATION

Date: Tue, 22 Nov 2022 06:56:09 +0600

https://bit.ly/3tO993c

Send a report that this bug log contains spam.