Re: [-debian-policy-] limiting user access
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.''
Reply to: