Re: Installing debs on shared file-systems (eg NFS)
>>>>> "Brian" == Brian May <bam@debian.org> writes:
Brian> Hello All, I have a proposal to make installing deb
Brian> packages on systems with shared file-systems (eg. diskless
Brian> systems, shared /usr, etc) easier, and more professional
Brian> (ie. remove the current "hack" requirement).
>>>>> In article <Pine.LNX.4.10.10008031018340.24681-100000@riemann.nyongwa.montreal.qc.ca>, Steve Robbins <steve@nyongwa.montreal.qc.ca> writes:
Steve> Important
Steve> As this document is based on pototo, ^^^^^^ oops! ;-)
As explained, I did that on purpose. Otherwise, I could not keep
up-to-date with the examples I have listed (if I mentioned problems in
woody, they would probably get fixed).
>>>>> In article <20000803144847.C13097@fdragon.lan>, Fire Dragon <fdragon@io.com> writes:
Fire> cool, where do I sign up to test / help with this? I am
Fire> trying to install a small cluster of 486's with a shared
Fire> /usr, /home and many parts of /var (like mail).
No, it requires heaps more work before you can even think about using
it on diskless systems.
>> However, this involves changing every package, so don't expect
>> results before hamm, err, I mean woody+1, at the earliest (even
>> this is probably highly optimistic ;-) ).
Fire> Hrrm... how about a possibility of the RedHat style
Fire> (basically pass a -X to the tar/cpio to exclude the nfs
Fire> mounted directories) but then again that is not as good as I
Fire> thought it was at first.
That solves part of the problem (and I think something like that would
have to be used), however the maintainer scripts would fail. My
proposal tries to fix the problem with the maintainer scripts.
>> This proposal also has implications for security when
>> installing untrusted deb packages, reducing the number of
>> annoying bugs in maintainer scripts, etc.
Fire> Does this mean for the possibility of embeded signatures in
Fire> the debs similar to the way redhat does things? (sorry for
Fire> compairing to redhat... it just was a good idea)?
Not quite. Signatures would be good, but that already has been
discussed elsewhere, and has nothing to do with my proposal.
Rather, the postinst script is divided into sections. Each section has
to declare what other files it needs to read from and write to. So,
the theory goes, the script could be called from a chroot environment,
which the required files automatically copied into/out of the chroot
environment. This would make it impossible for the postinst script to
modify any other files.
This means you could install a non-trusted package, and not worry
about it damaging your system, except for the following cases:
- if the package declares it wants to alter /etc/passwd, nothing is
stopping it... (perhaps some automatic algorithm could be used to
prevent such packages from being installed in the first place?).
- if the package installs daemons that run as root... (the administrator
could prevent daemons from automatically starting in the first place.).
- when the user runs binaries that were installed. even worse, if the
user happens to have root privileges at the time.
However, for this benefit, dpkg would need to be modified to use the
XML file instead of conventional maintainer scripts. This is the last
step on my list (actually, it isn't on my todo list at all).
I have a sample of how this could be done (it won't work at the
moment, there are some issues I still need to address), see
http://snoopy.apana.org.au/~bam/debian/
--
Brian May <bam@debian.org>
Reply to: