Bug#21941: dpkg usage of /var
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
--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#21941: dpkg usage of /var
Hi, Guillem Jover 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. -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#21941: dpkg usage of /var
* Guillem Jover (guil...@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 -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#21941: dpkg usage of /var
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/ 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 -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Processed: Re: Bug#21941: dpkg usage of /var
Processing commands for cont...@bugs.debian.org: > tag 21941 wontfix Bug #21941 [dpkg] scripts under /var prevent mounting /var with noexec Added tag(s) wontfix. > thanks Stopping processing here. Please contact me if you need assistance. -- 21941: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=21941 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#21941: dpkg usage of /var
Hi, 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. 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/ 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 -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#21941: dpkg usage of /var
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 -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
