Debian Bug report logs - #11018
dpkg violates FSSTND :(

Toggle useless messages

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

From: Chris Fearnley <cjf@cyberworldnet.com>

To: submit@bugs.debian.org

Subject: dpkg violates FSSTND :(

Date: Thu, 3 Jul 1997 22:36:30 -0400 (EDT)

Package: dpkg
Version: 1.4.0.8

dpkg stores executable files (namely, the package management scripts
{pre,post}{rm,inst}) under /var/lib.  They should be stored in /usr/sbin,
since they are static executables used in system administration.

This is a significant point, because it is reasonable to mount /var with
the noexec option.  Especially if /tmp is a link to /var/tmp and you don't
want your users running programs that they manage to get into /tmp!
However, the current dpkg will break if /var is mounted noexec, yuk.

-- 
Christopher J. Fearnley          |  Cyberworld Net System Engineering
cjf@cyberworldnet.com            |  Design Science Revolutionary
http://www.netaxs.com/~cjf       |  Explorer in Universe
ftp://ftp.netaxs.com/people/cjf  |  "Dare to be Naive" -- Bucky Fuller 

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

From: "James R. Van Zandt" <jrv@vanzandt.mv.com>

To: cjf@cyberworldnet.com, 11018@bugs.debian.org

Subject: Re: Bug#11018: dpkg violates FSSTND :(

Date: Fri, 4 Jul 1997 09:44:07 -0400 (EDT)

Chris Fearnley <cjf@cyberworldnet.com> writes:
>dpkg stores executable files (namely, the package management scripts
>{pre,post}{rm,inst}) under /var/lib.  They should be stored in /usr/sbin,
>since they are static executables used in system administration.

They can go under lib because they are not executed directly by either
the user or sysadmin.  They should go under /var because they are
machine-specific, whereas files under /usr can be shared.

>This is a significant point, because it is reasonable to mount /var with
>the noexec option.  Especially if /tmp is a link to /var/tmp and you don't
>want your users running programs that they manage to get into /tmp!
>However, the current dpkg will break if /var is mounted noexec, yuk.

If you are concerned about /tmp mount options, then put it on a
different partition.  You seem to have a pretty restrictive security
policy, though.  I suppose you don't allow your users execute programs
out of their home directories either?

                           - Jim Van Zandt

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

From: Chris Fearnley <cjf@cyberworldnet.com>

To: jrv@vanzandt.mv.com (James R. Van Zandt)

Cc: cjf@cyberworldnet.com, 11018@bugs.debian.org

Subject: Re: Bug#11018: dpkg violates FSSTND :(

Date: Fri, 4 Jul 1997 11:41:24 -0400 (EDT)

'James R. Van Zandt wrote:'
> 
> Chris Fearnley <cjf@cyberworldnet.com> writes:
> >dpkg stores executable files (namely, the package management scripts
> >{pre,post}{rm,inst}) under /var/lib.  They should be stored in /usr/sbin,
> >since they are static executables used in system administration.
> 
> They can go under lib because they are not executed directly by either
> the user or sysadmin.  They should go under /var because they are
> machine-specific, whereas files under /usr can be shared.

I sometimes run them as the sysadmin.  They are not machine-specific
they are (every one!) machine independent perl and sh scripts.

> >This is a significant point, because it is reasonable to mount /var with
> >the noexec option.  Especially if /tmp is a link to /var/tmp and you don't
> >want your users running programs that they manage to get into /tmp!
> >However, the current dpkg will break if /var is mounted noexec, yuk.
> 
> If you are concerned about /tmp mount options, then put it on a
> different partition.  You seem to have a pretty restrictive security
> policy, though.  I suppose you don't allow your users execute programs
> out of their home directories either?

I've been exploring a minimal allow security policy.  Of course, there are
other ways to achieve it.  But dpkg is the only program that puts
executables under /var/lib (well, "find /var -type f -perm +111 -ls"
found /var/spool/lpd/lj2p/.seq with the execute bit set, but it is
not a script).  This restricts my options.  I think it is a mistake.

Why isn't /usr/sbin more appropriate?

-- 
Christopher J. Fearnley          |  Cyberworld Net System Engineering
cjf@cyberworldnet.com            |  Design Science Revolutionary
http://www.netaxs.com/~cjf       |  Explorer in Universe
ftp://ftp.netaxs.com/people/cjf  |  "Dare to be Naive" -- Bucky Fuller 

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

From: Joey Hess <joey@kite.ml.org>

To: Chris Fearnley <cjf@cyberworldnet.com>, 11018@bugs.debian.org

Cc: "James R. Van Zandt" <jrv@vanzandt.mv.com>

Subject: Re: Bug#11018: dpkg violates FSSTND :(

Date: Fri, 4 Jul 1997 13:29:21 -0400

Chris Fearnley:
> I've been exploring a minimal allow security policy.  Of course, there are
> other ways to achieve it.  But dpkg is the only program that puts
> executables under /var/lib (well, "find /var -type f -perm +111 -ls"
> found /var/spool/lpd/lj2p/.seq with the execute bit set, but it is
> not a script).  This restricts my options.  I think it is a mistake.
> 
> Why isn't /usr/sbin more appropriate?

I don't think it should be diereclty on root's path.. and I don't really
want 600 more exceutables in /usr/sbin on my system.

Putting it in /usr is good sense, though. Maybe /usr/lib/dpkg/info?

-- 
see shy jo

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

From: James Troup <J.J.Troup@comp.brad.ac.uk>

To: Chris Fearnley <cjf@cyberworldnet.com>, 11018@bugs.debian.org

Subject: Re: Bug#11018: dpkg violates FSSTND :(

Date: 04 Jul 1997 19:01:00 +0100

Chris Fearnley <cjf@cyberworldnet.com> writes:

[ Something about where {{pre,post}{inst,rm}} scripts should go ]

[ they == {{pre,post}{inst,rm}} ]

> They are not machine-specific they are (every one!) machine
> independent perl and sh scripts.

Not necessarily, I *had* to use something other than a shell script
postinst for libreadline2_2.1-2.1 due to the problems of moving
libreadline from one directory to another and /bin/sh being
disfunctional.  I chose a C wrapper, there's nothing against that in
policy.

Not to mention that there is machine dependence in some of the machine
independent scripts (e.g. gnat, libc4, perl and emacs).

-- 
James

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

From: "Christian Hudon" <chudon@ee.mcgill.ca>

To: Chris Fearnley <cjf@cyberworldnet.com>, 11018@bugs.debian.org

Subject: Re: Bug#11018: dpkg violates FSSTND :(

Date: Fri, 4 Jul 1997 16:09:03 +0000

[Message part 1 (text/plain, inline)]

On Jul 3, Chris Fearnley wrote
> Package: dpkg
> Version: 1.4.0.8
> 
> dpkg stores executable files (namely, the package management scripts
> {pre,post}{rm,inst}) under /var/lib.  They should be stored in /usr/sbin,
> since they are static executables used in system administration.

Yuck! Not in /usr/sbin. The scripts are used only by dpkg, so they should
be under /something/lib/dpkg, not elsewhere.

  Christian

[Message part 2 (application/pgp-signature, inline)]

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

From: Dale Scheetz <dwarf@polaris.net>

To: Joey Hess <joey@kite.ml.org>, 11018@bugs.debian.org

Cc: Chris Fearnley <cjf@cyberworldnet.com>, "James R. Van Zandt" <jrv@vanzandt.mv.com>, Klee Dienes and Ian Jackson <dpkg-maint@chiark.greenend.org.uk>

Subject: Re: Bug#11018: dpkg violates FSSTND :(

Date: Fri, 4 Jul 1997 16:34:30 -0400 (EDT)

On Fri, 4 Jul 1997, Joey Hess wrote:

> Chris Fearnley:
> > I've been exploring a minimal allow security policy.  Of course, there are
> > other ways to achieve it.  But dpkg is the only program that puts
> > executables under /var/lib (well, "find /var -type f -perm +111 -ls"
> > found /var/spool/lpd/lj2p/.seq with the execute bit set, but it is
> > not a script).  This restricts my options.  I think it is a mistake.
> > 
> > Why isn't /usr/sbin more appropriate?
> 
> I don't think it should be diereclty on root's path.. and I don't really
> want 600 more exceutables in /usr/sbin on my system.
> 
> Putting it in /usr is good sense, though. Maybe /usr/lib/dpkg/info?
> 
I don't like the idea of putting them in /usr any better than where they
are. These aren't intended to be user programs. This is intended to be in
"isolated" package management archive/database not a pool of user scripts.

Luck,

Dwarf
-- 
_-_-_-_-_-_-                                          _-_-_-_-_-_-_-

aka   Dale Scheetz                   Phone:   1 (904) 656-9769
      Flexible Software              11000 McCrackin Road
      e-mail:  dwarf@polaris.net     Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-

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

From: joey@finlandia.infodrom.north.de (Martin Schulze)

To: dwarf@polaris.net (Dale Scheetz), 11018@bugs.debian.org

Cc: joey@kite.ml.org (Joey Hess), 11018@bugs.debian.org, cjf@cyberworldnet.com (Chris Fearnley), jrv@vanzandt.mv.com (James R. Van Zandt), dpkg-maint@chiark.greenend.org.uk (Klee Dienes and Ian Jackson)

Subject: Re: Bug#11018: dpkg violates FSSTND :(

Date: Sat, 5 Jul 1997 00:00:48 +0200

Dale Scheetz writes:

> > > I've been exploring a minimal allow security policy.  Of course, there are
> > > other ways to achieve it.  But dpkg is the only program that puts
> > > executables under /var/lib (well, "find /var -type f -perm +111 -ls"
> > > found /var/spool/lpd/lj2p/.seq with the execute bit set, but it is
> > > not a script).  This restricts my options.  I think it is a mistake.
> > > 
> > > Why isn't /usr/sbin more appropriate?
> > 
> > I don't think it should be diereclty on root's path.. and I don't really
> > want 600 more exceutables in /usr/sbin on my system.
> > 
> > Putting it in /usr is good sense, though. Maybe /usr/lib/dpkg/info?
> > 
> I don't like the idea of putting them in /usr any better than where they
> are. These aren't intended to be user programs. This is intended to be in
> "isolated" package management archive/database not a pool of user scripts.

Therefore to my understanding they belong to /var/lib/dpkg/*  They
are quite variable _during_ dpkg runs.  I could imagine that this
is the reason why we have /var/lib/news/active instead of
/usr/lib/news/active.

Regards

	Joey

-- 
  / Martin Schulze  *  joey@infodrom.north.de  *  26129 Oldenburg /
 /                                     http://home.pages.de/~joey/
/ Kernel-Patching in DOS? Selten so gelacht!   -- Jochen Schoof /

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

From: Joey Hess <joey@kite.ml.org>

To: Martin Schulze <joey@finlandia.infodrom.north.de>

Cc: Dale Scheetz <dwarf@polaris.net>, 11018@bugs.debian.org, Joey Hess <joey@kite.ml.org>, Chris Fearnley <cjf@cyberworldnet.com>, "James R. Van Zandt" <jrv@vanzandt.mv.com>, Klee Dienes and Ian Jackson <dpkg-maint@chiark.greenend.org.uk>

Subject: Re: Bug#11018: dpkg violates FSSTND :(

Date: Fri, 4 Jul 1997 19:36:34 -0400

Martin Schulze:
> Therefore to my understanding they belong to /var/lib/dpkg/*  They
> are quite variable _during_ dpkg runs.

This argument doesn't hold water, becuase all of /usr is rather variable
during dpkg runs.

-- 
see shy jo

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

From: Chris Fearnley <cjf@cyberworldnet.com>

To: joey@kite.ml.org (Joey Hess)

Cc: cjf@cyberworldnet.com, 11018@bugs.debian.org, jrv@vanzandt.mv.com

Subject: Re: Bug#11018: dpkg violates FSSTND :(

Date: Fri, 4 Jul 1997 22:14:53 -0400 (EDT)

'Joey Hess wrote:'
> Chris Fearnley:
> > Why isn't /usr/sbin more appropriate?
> 
> I don't think it should be diereclty on root's path.. and I don't really
> want 600 more exceutables in /usr/sbin on my system.

Why not on root's PATH?

> Putting it in /usr is good sense, though. Maybe /usr/lib/dpkg/info?

I thought /usr/sbin because
  o They are executables (hence should be in some bin directory)
  o They are used in system administration (hence should be in an sbin
    directory)
  o They are static data (at least as static as the rest of /usr; and hence
    shouldn't be in /var)

-- 
Christopher J. Fearnley          |  Cyberworld Net System Engineering
cjf@cyberworldnet.com            |  Design Science Revolutionary
http://www.netaxs.com/~cjf       |  Explorer in Universe
ftp://ftp.netaxs.com/people/cjf  |  "Dare to be Naive" -- Bucky Fuller 

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

From: Joey Hess <joey@kite.ml.org>

To: Chris Fearnley <cjf@cyberworldnet.com>

Cc: Joey Hess <joey@kite.ml.org>, 11018@bugs.debian.org, jrv@vanzandt.mv.com

Subject: Re: Bug#11018: dpkg violates FSSTND :(

Date: Fri, 4 Jul 1997 22:18:29 -0400

Chris Fearnley:
> Why not on root's PATH?

Because you really don't typically run them, and running some of them by
mistake (esp some of the postrm scripts) could be disasterous. /etc/init.d
isn't in the default path, and the stuff in there gets run a lot more often 
by root during day to day operations. (I've only had to run postinst scripts
by  hand a few times.)

-- 
see shy jo

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

From: Christian Schwarz <schwarz@monet.m.isar.de>

To: Chris Fearnley <cjf@cyberworldnet.com>, 11018@bugs.debian.org

Cc: Joey Hess <joey@kite.ml.org>, jrv@vanzandt.mv.com, debian-bugs-dist@lists.debian.org, Klee Dienes and Ian Jackson <dpkg-maint@chiark.greenend.org.uk>

Subject: Re: Bug#11018: dpkg violates FSSTND :(

Date: Sat, 5 Jul 1997 20:36:33 +0200 (CEST)

On Fri, 4 Jul 1997, Chris Fearnley wrote:

> 'Joey Hess wrote:'
> > Chris Fearnley:
> > > Why isn't /usr/sbin more appropriate?
> > 
> > I don't think it should be diereclty on root's path.. and I don't really
> > want 600 more exceutables in /usr/sbin on my system.
> 
> Why not on root's PATH?
> 
> > Putting it in /usr is good sense, though. Maybe /usr/lib/dpkg/info?
> 
> I thought /usr/sbin because
>   o They are executables (hence should be in some bin directory)
>   o They are used in system administration (hence should be in an sbin
>     directory)
>   o They are static data (at least as static as the rest of /usr; and hence
>     shouldn't be in /var)

I disagree to the second point: these scripts are usually not of interest
to the sysadmin. I'd rather consider them as "libs". So why not
/usr/lib/dpkg/info ?


Thanks,

Chris

--                  Christian Schwarz
                   schwarz@monet.m.isar.de, schwarz@schwarz-online.com
                  schwarz@debian.org, schwarz@mathematik.tu-muenchen.de
                       
                PGP-fp: 8F 61 EB 6D CF 23 CA D7  34 05 14 5C C8 DC 22 BA
              
 CS Software goes online! Visit our new home page at
 	                                     http://www.schwarz-online.com

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

From: Brian White <bcwhite@verisim.com>

To: Chris Fearnley <cjf@cyberworldnet.com>, 11018@bugs.debian.org

Cc: "James R. Van Zandt" <jrv@vanzandt.mv.com>

Subject: Re: Bug#11018: dpkg violates FSSTND :(

Date: Mon, 07 Jul 1997 10:34:34 -0400

> > >dpkg stores executable files (namely, the package management scripts
> > >{pre,post}{rm,inst}) under /var/lib.  They should be stored in /usr/sbin,
> > >since they are static executables used in system administration.
> >
> > They can go under lib because they are not executed directly by either
> > the user or sysadmin.  They should go under /var because they are
> > machine-specific, whereas files under /usr can be shared.
> 
> I sometimes run them as the sysadmin.  They are not machine-specific
> they are (every one!) machine independent perl and sh scripts.

I sometimes run several things from /usr/lib.  That doesn't mean that they
are intended to be used as such.  Those scripts are intended to be called
from a driving program.  They should not be made publicly visible by
putting it in root's path.

A knowledgeable sysadmin is free to do as he/she sees fit, as always.

                                          Brian
                                 ( bcwhite@verisim.com )

-------------------------------------------------------------------------------
      You can never be too good looking or too well equipped.  -- Dilbert

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

From: "Christian Hudon" <chudon@ee.mcgill.ca>

To: Chris Fearnley <cjf@cyberworldnet.com>, 11018@bugs.debian.org

Cc: Joey Hess <joey@kite.ml.org>, jrv@vanzandt.mv.com

Subject: Re: Bug#11018: dpkg violates FSSTND :(

Date: Mon, 7 Jul 1997 14:43:03 +0000

[Message part 1 (text/plain, inline)]

On Jul 4, Chris Fearnley wrote
> 
> I thought /usr/sbin because
>   o They are executables (hence should be in some bin directory)
>   o They are used in system administration (hence should be in an sbin
>     directory)
>   o They are static data (at least as static as the rest of /usr; and hence
>     shouldn't be in /var)

Please reread the relevant sections of the FSSTND...

o Executables called only by the sysadmin (as opposed to every user) belong
in /usr/sbin (or /sbin)

o Executables called only by one program belong under /usr/lib/programname

So if the preinsts, postinsts, etc. are moving anywhere, they should go
somewhere under /usr/lib/dpkg.

...

And actually, here's why they should stay under /var/lib/dpkg: because they
need to stay in sync with the .list, .conffiles, etc. files. Putting some
of the files under /usr and some under /var is asking for trouble,
IMHO. Especially since /usr is meant to be shared... I really think the
{post,pre}{inst,rm} scripts should stay under /var. They should be thought
of as part of the current 'state' of dpkg on a given machine.

  Christian

[Message part 2 (application/pgp-signature, inline)]

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

From: Chris Fearnley <cjf@netaxs.com>

To: joey@kite.ml.org

Cc: 11018@bugs.debian.org, jrv@vanzandt.mv.com

Subject: Re: Bug#11018: dpkg violates FSSTND :(

Date: Tue, 8 Jul 1997 00:02:46 -0400 (EDT)

'Joey Hess wrote:'
>
>Chris Fearnley:
>> Why isn't /usr/sbin more appropriate?
>
>I don't think it should be diereclty on root's path.. and I don't really
>want 600 more exceutables in /usr/sbin on my system.
>
>Putting it in /usr is good sense, though. Maybe /usr/lib/dpkg/info?

I'm becoming persuaded of this location.  What do the dpkg maintainers
think?  They have been silent throughout this discussion.

-- 
Christopher J. Fearnley          |  Linux/Internet Consulting
cjf@netaxs.com                   |  Design Science Revolutionary
http://www.netaxs.com/~cjf       |  Explorer in Universe
ftp://ftp.netaxs.com/people/cjf  |  "Dare to be Naive" -- Bucky Fuller

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

From: Brian White <bcwhite@verisim.com>

To: Chris Fearnley <cjf@netaxs.com>, 11018@bugs.debian.org

Cc: joey@kite.ml.org, jrv@vanzandt.mv.com

Subject: Re: Bug#11018: dpkg violates FSSTND :(

Date: Thu, 10 Jul 1997 11:34:10 -0400

> >Putting it in /usr is good sense, though. Maybe /usr/lib/dpkg/info?
> 
> I'm becoming persuaded of this location.  What do the dpkg maintainers
> think?  They have been silent throughout this discussion.

I think it is wise to leave it under /var.

In the future, dpkg will support a local policies file that will allow
setting things like "don't install anything under /usr because it is read-
only NFS mounted".  Thus, dpkg won't actually write anything under /usr.

It could be aruged that the install scripts will then already be in
/usr/dpkg/..., but this isn't strictly true.  If we assume that the
file server is upgraded before the workstation, then the {pre,post}rm
scripts will be for the new version instead of the installed version.

                                          Brian
                                 ( bcwhite@verisim.com )

-------------------------------------------------------------------------------
   Give others some insight into YOUR pages!  http://www.verisim.com/insite/

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

From: Chris Fearnley <cjf@netaxs.com>

To: bcwhite@verisim.com (Brian White)

Cc: cjf@netaxs.com, 11018@bugs.debian.org, joey@kite.ml.org, jrv@vanzandt.mv.com

Subject: Re: Bug#11018: dpkg violates FSSTND :(

Date: Fri, 11 Jul 1997 18:11:07 -0400 (EDT)

'Brian White wrote:'
>
>> >Putting it in /usr is good sense, though. Maybe /usr/lib/dpkg/info?
>> 
>> I'm becoming persuaded of this location.  What do the dpkg maintainers
>> think?  They have been silent throughout this discussion.
>
>I think it is wise to leave it under /var.

Why should there be any executables under /var?  I see no reason and I
some advantages to mounting /var noexec.  Please present some
justification for keeping executables under /var.

-- 
Christopher J. Fearnley          |  Linux/Internet Consulting
cjf@netaxs.com                   |  Design Science Revolutionary
http://www.netaxs.com/~cjf       |  Explorer in Universe
ftp://ftp.netaxs.com/people/cjf  |  "Dare to be Naive" -- Bucky Fuller

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

From: Brian White <bcwhite@verisim.com>

To: Chris Fearnley <cjf@netaxs.com>

Cc: 11018@bugs.debian.org, joey@kite.ml.org, jrv@vanzandt.mv.com

Subject: Re: Bug#11018: dpkg violates FSSTND :(

Date: Fri, 11 Jul 1997 19:07:42 -0400

Chris Fearnley wrote:
> 
> 'Brian White wrote:'
> >
> >> >Putting it in /usr is good sense, though. Maybe /usr/lib/dpkg/info?
> >>
> >> I'm becoming persuaded of this location.  What do the dpkg maintainers
> >> think?  They have been silent throughout this discussion.
> >
> >I think it is wise to leave it under /var.
> 
> Why should there be any executables under /var?  I see no reason and I
> some advantages to mounting /var noexec.  Please present some
> justification for keeping executables under /var.


Does my original mail not provide this?

> >In the future, dpkg will support a local policies file that will allow
> >setting things like "don't install anything under /usr because it is read-
> >only NFS mounted".  Thus, dpkg won't actually write anything under /usr.
> >
> >It could be aruged that the install scripts will then already be in
> >/usr/dpkg/..., but this isn't strictly true.  If we assume that the
> >file server is upgraded before the workstation, then the {pre,post}rm
> >scripts will be for the new version instead of the installed version.

Thus, if we can't keep it under /usr, where will we keep it?

                                          Brian
                                 ( bcwhite@verisim.com )

-------------------------------------------------------------------------------
    In theory, theory and practice are the same.  In practice, they're not.

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

From: Anthony Towns <aj@azure.humbug.org.au>

To: dark@xs4all.nl (Richard Braakman)

Cc: debian-policy@lists.debian.org, 11018@bugs.debian.org

Subject: Re: [-debian-policy-] limiting user access

Date: 14 Feb 1998 17:45:17 +1000

dark@xs4all.nl (Richard Braakman) writes:
> [ moving dpkg/info to /usr/lib ]
> See bugreport #11018 for background information on this.  It has
> been discussed before :)

Thanks for the pointer.

]                         Debian bug report logs - #11018
]                             dpkg violates FSSTND :(

(much deleted. see the bug report for the full story)

] Date: Thu, 10 Jul 1997 11:34:10 -0400
] From: Brian White <bcwhite@verisim.com>
] Subject: Re: Bug#11018: dpkg violates FSSTND :(
]
] I think it is wise to leave it under /var.

For at least hamm, I'd say you're right. But it would be nice to be
able to keep user writable filesystems such as /var no-exec, so if
you'll allow me a flight of fantasy...

] In the future, dpkg will support a local policies file that will allow
] setting things like "don't install anything under /usr because it is read-
] only NFS mounted".  Thus, dpkg won't actually write anything under /usr.
]
] It could be aruged that the install scripts will then already be in
] /usr/dpkg/..., but this isn't strictly true.  If we assume that the
] file server is upgraded before the workstation, then the {pre,post}rm
] scripts will be for the new version instead of the installed version.

The way I understand this is that you're assuming something like:

Local: /, /var, &c.
Shared: /usr

Where you're upgrading something by upgrading the fileserver initially
(and hence /usr), then going around and changing each of the
workstations.

This seems a moderately dangerous way to do things, in that you're not
leaving the prerm script a working system -- it's executables are for
the next version, it's configs for the previous, so even the prerm
script can't rely on the behaviour of its executable, or, in the case
of removing a package, its very existence. This doesn't seem ideal to
me.

I'm not sure what an ideal solution would be, but I would expect it to
involve more than a flag like --no-usr-writes.

Two notes on the original topic, though: first, a new {pre,post}rm
should be able to cope with an old executable or configuration file
more easily than an old {pre,post}rm can cope with a new executable --
the past is much more predicatbale than the future.

Secondly, one possible (but not very neat) way of solving the
mentioned problem would be to have (something like)

	server# dpkg --server-upgrade -i xyzzy.deb

move the old prerm/postrm/whatever scripts to /usr/lib/dpkg/info-old,
at which point

	work42# dpkg --workstation-upgrade -i xyzzy.deb

would use the prerm/postrm/whatever scripts in dpkg/info-old to remove
the old version, and the dpkg/info scripts to install the new.

You could then run something akin to

	server# dpkg --finished-upgrade

or something to remove the dpkg/info-old directory.

In any case, either of the above suggestions should solve the specific
complaint with /usr/lib/dpkg/info.

(To keep the entire system in sync throughout the process, you'd
probably need to have each workstation do their prerms before any of
the postinsts are started. It seems like a tricky problem to solve
nicely in general)

] From: "Christian Hudon" <chudon@ee.mcgill.ca>
] Date: Mon, 7 Jul 1997 14:43:03 +0000
] Subject: Re: Bug#11018: dpkg violates FSSTND :(
]
] And actually, here's why they should stay under /var/lib/dpkg: because they
] need to stay in sync with the .list, .conffiles, etc. files. 

Isn't this why we have a packaging system in the first place?

] Putting some
] of the files under /usr and some under /var is asking for trouble,
] IMHO. Especially since /usr is meant to be shared... I really think the
] {post,pre}{inst,rm} scripts should stay under /var. They should be thought
] of as part of the current 'state' of dpkg on a given machine.

In which case they're guaranteed to be wrong for some of the machines
at some point during an upgrade of shared files whichever way you go.

I'll certainly concede that using /var is less likely to cause
problems in the short term, but it does seem to me that moving
executables out of /var would be a good idea.

When we move to the FHS, perhaps /opt/package/{pre,post}{inst,rm}
would be the way to go.

Cheers,
aj

-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP encrypted mail preferred.

      ``It's not a vision, or a fear. It's just a thought.''

Send a report that this bug log contains spam.