Limiting the power of package installation in Debian
There is always at least a small risk when installing a package for a distribution. By its very nature, package installation is an invasive process; some packages require the ability to make radical changes to the system—changes that users surely would not want other packages to take advantage of. Packages that are made available by distributions are vetted for problems of this sort, though, of course, mistakes can be made. Third-party packages are an even bigger potential problem because they lack this vetting, as was discussed in early October on the debian-devel mailing list. Solutions in this area are not particularly easy, however.
Lars Wirzenius brought
up the problem: "when a .deb package is installed, upgraded, or
removed,
the maintainer scripts are run as root and can thus do anything.
"
Maintainer
scripts are included in a .deb file to be run before and after
installation or removal.
As he noted, maintainer scripts for third-party packages (e.g. Skype,
Chrome) sometimes add
entries to the lists of
package sources and signing keys; they do so in order to get security
updates to their packages safely, but it may still be surprising or
unwanted. Even simple mistakes made in Debian-released packages might
contain unwelcome surprises of various sorts.
He suggested that there could be a set of "profiles" that describe the kinds of changes that might be made by a package installation. He gave a few different examples, such as a "default" profile that only allowed file installation in /usr, a "kernel" profile that can install in /boot and trigger rebuilds of the initramfs, or "core" that can do anything. Packages would then declare which profile they required. The dpkg command could arrange that package's install scripts could only make the kinds of changes allowed by its profile. Mostly, he wanted to spark some discussion:
As Paul Wise pointed
out, though, maintainer scripts are not the only problem. There are
lots of ways ("setuid binaries, cron jobs, systemd units, apt keyring
information, sudoers files and so on
") that a malicious package
could compromise the system. He
pointed to a wiki page
created by Antoine Beaupré to document the problem of untrusted
.deb files along with some possible solutions. Wise suggested
that Flatpak might also provide part of the
solution.
Beaupré agreed that there are numerous problem areas in the current installation mechanism. He would like to see Debian look at fixing some of them, even if it doesn't lead to fixing them all:
For example, there's no reason why a package like Chromium should be able to run stuff as root. The vast majority of third-party repositories out there mostly ship this one binary that does not require special privileges other than installing stuff in /usr, without suid or any special permissions.
He suggested some low-hanging fruit, like changing maintainer scripts to
use a
declarative syntax rather than be open-ended shell scripts. Switching Debian
to use Flatpak, which wasn't quite what
Wise meant, "would be a
rather controversial
change
", but the Flatpak project is working to address many of the
problems
under discussion, so it may make sense to look at it in more detail,
Beaupré said.
Protecting against malicious .deb files is too high of a hurdle to realistically clear, according to several in the thread. W. Martin Borgert said:
Ralf Treinen concurred
with that, but noted that it is difficult to know if a script is doing
something that it shouldn't. "Having a declaration
of what the maintainer thinks are the possible effects of a script
would certainly help us.
" But Guillem Jover rejected
the whole idea of ever securely installing untrusted .deb files: "If you do not trust the .deb, then you
should not be even installing it using dpkg, less running it unconfined,
as its paradigm is based on fully trusting the .debs, on using shared
resources, and on system integration.
" He went on to list multiple
areas that would need attention, concluding that if all of those things
were fixed, it wouldn't be much like today's packages "except for the
container format. :)
".
While protecting against malicious packages may not really be in the cards for .deb files, Flatpak (or other, similar ideas such as Ubuntu's .snap packages) may eventually provide some of that kind of protection. That is not really something that Debian can control; users have shown that they want various third-party tools and the makers of those tools are going to do what they think they need to do in terms of installation. If Debian gets in the way of that, it is likely to lead to it becoming less relevant.
The way that packages are
built and maintained for Debian is already complicated enough, Tomas
Pospisek said:
"I think Linux systems per se, Debian as a runtime, the (social)
processes required from DDs/DMs, the whole technical Debian packaging
ecosystem are each plenty complex enough already.
" Adding to that
will just make it "less fun
" leading to fewer Debian Developers
and Maintainers (DDs/DMs), less software being packaged, and, ultimately,
fewer users.
There is appeal to protecting packagers and users from silly errors; as
Paride Legovini put
it: "I
know I won't screw up anybody's system with a font package as I
restricted it to /usr/share and /etc/fonts.
" But the problem with
things like Chrome and Skype that Wirzenius started out with is not really
amenable to the (not fully baked) solution he described. Profiles might
help Debian package maintainers, but are not likely to help with
third-party packages. Legovini continued:
Some kind of declarative system for package installation is one solution
that could help. Packages could only perform the actions allowed by the
package manager—not arbitrary shell commands. Simon Richter described
what that might look like in some detail. Wise also pointed
out that the dpkg maintainers do have declarative
packaging "on their radar
".
No grand conclusions came from the discussion, but that is partly because there were several different aspects under consideration. Preventing Debian packagers from inadvertently causing installation errors is a much more tractable problem than trying to prevent malicious .deb files from wreaking havoc. And non-malicious third-party packages, though possibly buggy or taking undue liberties, are yet again a somewhat different problem. The problem is not limited to Debian either, of course; package installation on any distribution is likely to suffer from most of the same problems. It is good to see discussion in this area, if only to keep it in mind as packaging evolves down the road.
| Index entries for this article | |
|---|---|
| Security | Distribution security |
Posted Nov 7, 2018 18:42 UTC (Wed)
by jccleaver (guest, #127418)
[Link] (10 responses)
Any given RPM can have its entire file list exploded before install, and the scripts run are visible via a simple rpm -q --scripts -p <pkgname>. The file list includes the associated user/group and permissions ahead of time and could be examined for untrusted or unexpected entries.
An RPM scriptlet can call a script that the RPM itself lays down in %post, of course (and in fact, plenty of packages do that for things like data initialization or whatnot), but individual files can be extracted and examined ahead of time (using cpio) if there is a specific concern.
Some of these things sound a little interesting -- I could see value in write-protecting /boot maybe. I had thought an inotify for any non-t_tmp file not owned by the package being modified during %post could be flaggable, but I could also see that resulting in an endless prompt of Vista-esque UAC confirmations.
Ultimately, I guess I'm just a bit confused. A competent sysadmin has ways of examining an untrustworthy RPM, but the entire point of OSS (which GNU/Linux is an environment of) is that the person doing the work has methods for varying levels of introspection into what's going on, and it feels like the RPM format (and ecosystem of tools) provides mechanisms for that. Does dpkg and the .deb format not?
Posted Nov 7, 2018 18:51 UTC (Wed)
by zyga (subscriber, #81533)
[Link]
Posted Nov 7, 2018 19:33 UTC (Wed)
by rweikusat2 (subscriber, #117920)
[Link] (1 responses)
Besides the option of disassembling the archive manually, the dpkg-deb command can be used to access the contents. Assuming a package file named uselessd_1.52.11_amd64.deb, the command
Posted Nov 9, 2018 16:07 UTC (Fri)
by ceplm (subscriber, #41334)
[Link]
Posted Nov 7, 2018 21:19 UTC (Wed)
by roc (subscriber, #30627)
[Link] (1 responses)
A sysadmin or normal user who would rather check a label than inspect package contents isn't necessarily "incompetent" or "lazy", they may just have better things to do with their time.
Posted Nov 7, 2018 21:39 UTC (Wed)
by jccleaver (guest, #127418)
[Link]
That seems like an impossible thing to guarantee in and of itself. File ownership, sure, but a general Linux system will be able intake config files in a number of ways that could involve root. You might as well try to guarantee against buffer overflows. Relying solely on install-time packaging tools for this (which would be a necessary component of this in order to provide any actual time savings for an admin) would be risky at best.
A better option might be to enforce MAC and flag packages that have any files installing in an unconfined domain onto the system. An included SELinux policy (required to do anything useful) in the package could then be scanned and presented in some sort of readable way for approval prior to manual install.
Posted Nov 8, 2018 8:31 UTC (Thu)
by mjthayer (guest, #39183)
[Link] (1 responses)
Posted Nov 17, 2018 3:46 UTC (Sat)
by ssokolow (guest, #94568)
[Link]
That's actually one of the advantages Snappy claims over Flatpak.
Posted Nov 9, 2018 0:12 UTC (Fri)
by Rudd-O (guest, #61155)
[Link] (2 responses)
Posted Nov 9, 2018 9:55 UTC (Fri)
by guillemj (subscriber, #49706)
[Link]
Posted Nov 9, 2018 21:10 UTC (Fri)
by rweikusat2 (subscriber, #117920)
[Link]
Posted Nov 7, 2018 18:45 UTC (Wed)
by Baughn (subscriber, #124425)
[Link] (5 responses)
Nix packages are built in a jail, and can *only* output a tree of files. That tree is merged with that of every other package in the profile, so you get the same bin/man/etc. directories as otherwise, but filename clashes are detected and can be handled appropriately. It isn't even possible to create a SUID binary this way; installing a package is, by itself, quite safe.
Packages that need to do system-wide configuration have to be built as NixOS modules, which could be an overlay, but this normally means they have to be packaged in the distribution's github repository -- which is far easier to contribute to than Debian. Any breakage usually happens at "compile-time" (for the OS, not the package), and in the event a non-malicious package broke your system, you can always roll back to the previous version.
Of course this all comes at a cost, but there are many, many benefits besides this one.
Posted Nov 7, 2018 20:40 UTC (Wed)
by atai (subscriber, #10977)
[Link]
Posted Nov 8, 2018 10:55 UTC (Thu)
by federico3 (guest, #101963)
[Link] (1 responses)
The ability to run scripts as root is not a bug, but a feature. Debian and RPM based distributions have been building the file tree and checking for collisions before installation since decades.
The use of such scripts is minimal for official packages and they are reviewed and vetted before upload.
Posted Nov 15, 2018 14:22 UTC (Thu)
by HelloWorld (guest, #56129)
[Link]
Services are expected to be able to reload their configuration using the `systemctl reload` command. So packages could simply specify declaratively which services need to reload their configuration and then the package manager can do that. And it's better, because the package manager would only do this once per service, even if you install several such packages at once.
Posted Nov 9, 2018 6:23 UTC (Fri)
by flussence (guest, #85566)
[Link] (1 responses)
The installation *can* run things as root after merging files, but any shady business will stick out like a sore thumb during code review, simply because needing to do so at all is so rare. It helps that things like messing with existing config and running services during package installation are culturally verboten.
Posted Nov 17, 2018 16:52 UTC (Sat)
by hvd (guest, #128680)
[Link]
Posted Nov 7, 2018 18:48 UTC (Wed)
by zyga (subscriber, #81533)
[Link]
Scaling this idea to Debian is not going to be easy because of the huge surface area but I think that attempting to solve the problem is a valid and worthy goal to pursue.
Posted Nov 8, 2018 5:29 UTC (Thu)
by interalia (subscriber, #26615)
[Link]
Yes, though it would be interesting if you could set these profile types in the APT source list, so that the tools could tell if you a package specified a profile other than the ones you have allowed. That way if the latest version of the Chromium 3rd-party package was profile "core" and I have it in my sources.list as "default" then APT/dpkg could decline to install it (or prompt).
It would not, as everyone agrees, prevent malicious changes, so I'm not sure the small gain (preventing/alerting of buggy/inadvertent changes) is worth the effort except if it prevents upload of the buggy packages in the first place.
Posted Nov 8, 2018 10:36 UTC (Thu)
by NAR (subscriber, #1313)
[Link] (14 responses)
LWN itself mentioned the "curl | sudo" pattern, which seems to get more and more popular. Essentially it's the same as Windows/OS X uses: download an .exe/.dmg and execute it, when prompted for password, type it. Even if the developers want to play nice and provide a .deb (or RPM) package, they provide it via their own repository, so they can release on their own schedule (which might be a lot faster or just simply different than the distribution's schedule). Also in single user desktops it doesn't really matter much if there's some code running as root - the important data is accessible by the user.
Posted Nov 8, 2018 12:58 UTC (Thu)
by andrewsh (subscriber, #71043)
[Link] (2 responses)
Posted Nov 15, 2018 14:03 UTC (Thu)
by HelloWorld (guest, #56129)
[Link] (1 responses)
Posted Nov 21, 2018 2:22 UTC (Wed)
by flussence (guest, #85566)
[Link]
Posted Nov 8, 2018 13:18 UTC (Thu)
by raimue (subscriber, #95875)
[Link] (2 responses)
Of course there is no Debian package for every single module available on PyPi, CPAN, etc. Only if you want to package software that needs a Python or Perl module, you also need a package for this module. This is a requirement to properly handle dependencies. Packaging the module and inclusion in the Debian repository ensures the required module (and especially exactly this tested version) will always be available through the lifetime of the Debian package. The list of the modules you will find in Debian will mostly be what other packages required and was packaged for this purpose.
Note that these Debian packages can often be generated automatically based on an upstream index such as PyPi or CPAN. https://wiki.debian.org/AutomaticPackagingTools
Posted Nov 8, 2018 14:41 UTC (Thu)
by drag (guest, #31333)
[Link] (1 responses)
As the FLOSS ecosystem increases in size it also increases in complexity and it also increases in speed. Both in terms of rate that software is written, but also in the rate of innovation. Now with dependencies it's not a issue of what makes software work within a OS, but what makes it worth within a organization or within a entire ecosystem.
Debian must operate under it's own time tables and follow it's own rules and unfortunately those time tables and rules rarely match up with anybody else's. With distribution's the software versions you can use is tied to the timetable set by that distribution's release strategy. A lot of the time it doesn't matter exactly what version of software you are using... Emacs latest release works about as well as a release from 2 years ago or 6 months ago. Same thing with compilers and terminals and whatnot.
But the same is not true for, say... Docker, kubespray, helm, vault, ansible, and cfssl. With tools like 'asdf' package manager (github.com/asdf-vm/asdf) I can install multiple versions of go, python, Erlang, and a half dozen other languages and their own language-specific package management systems and package versions.
I can use pipenv to setup different kinds of dependencies in a project, for example. I can setup dependency list for people who want to just run the software, but then I can setup a dependency list of pip packages for when you want to participate in the development process and their versions... and the versions of software needed to work with the CI pipeline or whatever.
And, sure, it's a mess and terrible and probably has lots of security deficiencies. But none of these things are tied specifically to your OS and your OS release versions like distribution packages are. And it works in pretty much any Linux distribution you want. And it works in OS X and most it mostly works in Windows. And the problems people are trying to address with these tools are unlikely to be addressed by any distribution-specific tool.
So not only you get the benefit of everybody using the software in any Linux distribution you also get the benefit of everybody using it in OS X and other operating systems. As these sort of tools gain in popularity the growth in change and innovation becomes almost exponential.
And while I see absolutely zero evidence to suggest that distributions and distribution packages are going away. (nor do I want them to go away... )What I do see is that distribution package management systems are increasingly relegated to simply setting up a base OS while other tools are used to manage most of the important software (from a perspective as a end user/developer/service provider) separate-but-on-top-of Linux distributions.
Posted Nov 8, 2018 15:05 UTC (Thu)
by rweikusat2 (subscriber, #117920)
[Link]
Posted Nov 8, 2018 16:24 UTC (Thu)
by jccleaver (guest, #127418)
[Link] (6 responses)
Anyone who runs "curl | sudo" deserves to have their root access taken away.
Posted Nov 8, 2018 18:03 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (4 responses)
Posted Nov 8, 2018 18:40 UTC (Thu)
by jccleaver (guest, #127418)
[Link] (3 responses)
If you think a .deb/.rpm package running a %post script is "sneaky", you might deserve to have your root access taken away too.
Posted Nov 8, 2018 18:42 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
Posted Nov 8, 2018 20:36 UTC (Thu)
by rweikusat2 (subscriber, #117920)
[Link] (1 responses)
Assuming an attempt was made to create sensible packages, one will have the usual benefits of using managed packages, eg, query which packages were installed, which files belong to which packages, update or remove installed packages easily, doing OS updates without "clean reinstalls" etc.
I've extensivley done both in the past and in my opinion, packages are a lot less of a hassle to deal with. YMMV. But it's worth a try.
Posted Nov 9, 2018 6:27 UTC (Fri)
by flussence (guest, #85566)
[Link]
In practice it's usually repositories run by billionaire corporations like Microsoft, Google and Valve that are the most likely to hurt you. Repositories where it's an actual person's neck on the line usually have some semblance of QA.
Posted Nov 8, 2018 21:24 UTC (Thu)
by NAR (subscriber, #1313)
[Link]
Posted Nov 15, 2018 5:12 UTC (Thu)
by gwg (guest, #20811)
[Link]
3rd party application support has always been poor in Linux, due to the dominance of Distro's - hence the "year of the Linux desktop" has never arrived.
Here's a classic user application install problem: How does an app add permissions for a particular USB device that it provides support for ? Unlike (say) MSWindows or OS X there is no standard API for this, and root is needed to modify/add udev rules and in any case, udev rule file syntax/conventions is a moving target.
Posted Nov 8, 2018 14:12 UTC (Thu)
by anarcat (subscriber, #66354)
[Link]
But even for those venerable package that go through the stations of the cross required to be bundled in the sacro-saint Debian archive, we do have a trust issue. Even as a Debian developper, I do not personally know every of the 600 Debian developer out there. I would like to *not* have to trust them.
And while some people might see this problem as a "wrong, non-achievable goal", I disagree. Many other distribution system out there, from flatpak to android APKs, are trying to solve exactly that problem. Why shouldn't we?
I know it's hard, but we have good targets we can work towards. I made a list, it's a start and I'm glad we're talking about it at least. Let's try to get there, at least.
Posted Nov 8, 2018 14:31 UTC (Thu)
by epithumia (subscriber, #23370)
[Link] (1 responses)
* All of the security issues highlighted in this article.
* In situations like Project Atomic scriptlets basically don't get run at all (because package installation doesn't happen on the machine which actually runs the installed packages) so alternate methods have to be used.
* Excessive complexity pushed to the packager that shouldn't be necessary.
* Scriptlets can introduce really unpleasant cyclical dependencies. Especially at install time, you may not be able to rely on being able to call the shell. RPM has an embedded Lua interpreter for this case, but that's even more complexity that the packager needs to care about.
* Scriptlets which modify existing data like configuration files are pretty scary in general.
Fedora has taken various steps to deal with scriptlets, including:
* Using the RPM "file trigger" system, to basically centralize scriptlets. This basically allows the package which "owns" a set of directories to provide scriptlets which are called when things are placed in those directories. So a package installing libraries no longer needs to care about calling ldconfig; the glibc package does that automatically.
* Providing single points of entry for important tasks which require scriptlets. So the scriptlet just calls a "do-something" executable instead of having a pile of shell. Which again allows the set of actions performed to evolve outside of the individual packages which need to perform them.
* Fixing upstream projects to accept "whatever.d" style configuration snippet directories so scriptlets aren't needed to modify the configuration of an existing setup.
Though it has taken some effort to get file triggers adopted in some of the very core packages like glibc (and is still not quite done for systemd services) the end result is that we've gone from having a whole pile of random mandatory scriptlets for various cases to... not nearly as many (but still a lot).
We would certainly like to get to a point where packages in the distribution simply don't have scriptlets. To the point that installing a package which does use scriptlets would be an exceptional act which could be flagged.
Posted Nov 8, 2018 15:30 UTC (Thu)
by rweikusat2 (subscriber, #117920)
[Link]
Posted Nov 9, 2018 10:26 UTC (Fri)
by nilsmeyer (guest, #122604)
[Link] (12 responses)
Posted Nov 9, 2018 10:46 UTC (Fri)
by karkhaz (subscriber, #99844)
[Link]
in short, run
# echo 'disable *' >> /etc/systemd/system-preset/99-default.preset
Posted Nov 9, 2018 11:57 UTC (Fri)
by esmil (subscriber, #82064)
[Link]
echo 'exit 101' > /usr/sbin/policy-rc.d
Posted Nov 9, 2018 16:06 UTC (Fri)
by jccleaver (guest, #127418)
[Link] (9 responses)
FWIW, this has been the policy in RedHat/Fedora forever. See https://fedoraproject.org/wiki/EPEL:SysVInitScripts#Why_d.......
Thanks to systemd making all sorts of scheisse technically a "service", there's a lot more that begins there, but even still an auto-starting-on-boot service needs to meet certain qualifications: https://fedoraproject.org/wiki/Packaging:DefaultServices
Either way, a service should *NEVER* be explicitly started up in a %post-RPM script, since you can't guarantee the situation you're installing in. For daemons, the most you do is a '/sbin/service <daemon> condrestart', which restarts it IFF it's already running.
Posted Nov 18, 2018 11:19 UTC (Sun)
by berndp (guest, #52035)
[Link] (8 responses)
And yes, security is the second reason (because folks may habe a daemon running without knowing it).
Posted Nov 18, 2018 14:29 UTC (Sun)
by jezuch (subscriber, #52988)
[Link] (4 responses)
Posted Nov 19, 2018 21:03 UTC (Mon)
by berndp (guest, #52035)
[Link] (3 responses)
In reality, that motto is good for the "don't care about security" faction as the stuff just runs (somehow ...).
Well, thank you for pointing out explicitly what folks can expect from Debian on a real server accessible to the real Internet ....
Posted Nov 20, 2018 11:24 UTC (Tue)
by laarmen (subscriber, #63948)
[Link] (2 responses)
Security is not a black-and-white issue. One might think that having a daemon automatically configured with sensible settings for basic, domestic use (such as, well, listening to localhost only), so that the user doesn't have to do anything, is better than having them copy-paste instructions from a random webpage on the Internet.
Posted Nov 20, 2018 11:58 UTC (Tue)
by karkhaz (subscriber, #99844)
[Link] (1 responses)
If all of that is true, then I'd be especially concerned because the openssh-server package is pulled in by the ssh metapackage. It wouldn't surprise me if a new user, being asked to install SSH, took that to mean running `apt-get install ssh` and therefore inadvertently ended up with sshd connected to the internet when all they wanted was the client (openssh-client).
Anyway, if daemons are started automatically but only listen to localhost, then that still contradicts the "just apt-install it" motto, since you'll need to edit sshd.conf to do anything useful. If you're going to make the user do work, it's surely better to have a sane default sshd.conf and ask them to run `systemctl start sshd`, than to ask them to edit a text file and run the same command, except for s/start/restart?
Posted Nov 20, 2018 14:22 UTC (Tue)
by laarmen (subscriber, #63948)
[Link]
I'm actually surprised, as Apache2 seems to listen to the outside by default (no fresh Debian at hand here though) even though there are relatively valid reasons to have a local-only web server. But in any cases, these are only examples, and I still think the policy of starting the services automatically with a sane default config is helpful for non-expert users, at the cost of a mild annoyance for the expert users.
Posted Nov 18, 2018 16:15 UTC (Sun)
by mpr22 (subscriber, #60784)
[Link] (1 responses)
Binary packages of daemons prepared by conscientious Linux distribution packagers are arranged like: (with foobard encouraging but not compelling you to install foobard-doc).
If all you want is the doc, you can then simply install foobard-doc and now you have the documentation but not the daemon, so there is no possible way for the daemon to run because it isn't on your system. Under that scheme, if foobard can be given a safe, sane default configuration for live systems, it's perfectly reasonable for the act of installing foobard through the package tool to also automatically start foobard. (And yes, the first statement of this post is intended as a dogmatic assertion that any Linux distribution packager who prepares the binary package of a daemon and its documentation as a monolithic lump is by definition not sufficiently conscientious.)
Posted Nov 19, 2018 20:55 UTC (Mon)
by berndp (guest, #52035)
[Link]
Posted Nov 18, 2018 22:43 UTC (Sun)
by rodgerd (guest, #58896)
[Link]
Indeed. "Listen on an open port by default" was one of the many things that Windows was ruthlessly (and rightly) mocked for at the start of the century.
Posted Nov 12, 2018 7:51 UTC (Mon)
by vadim (subscriber, #35271)
[Link] (2 responses)
99.9% of what I care about runs under my own user account. Great, a package can't mess around with /etc/shadow, but on a personal laptop, who cares? A malicious program running under my own account can set LD_PRELOAD, create aliases, or just read files in $HOME to get credit card data out of my browser. And then it can open a socket and transmit that data anywhere.
Not allowing it root access isn't going to make things a whole lot better.
Posted Nov 17, 2018 3:55 UTC (Sat)
by ssokolow (guest, #94568)
[Link]
(In the same way that there's no rush to solve difficult problems in X11 when they're already slated to be solved by Wayland+XWayland.)
.deb vs .rpm differences?
.deb vs .rpm differences?
A Debian package is basically an ar archive containing two compressed tarfiles, control.tar.gz and data.tar.gz (possibly using a different compression method and corresponding extension). The second contains the complete filesystem tree of the package and the first the packaging meta-files. That's mostly a header with a general package description (called control) and the so-called package maintainer scripts which will be run at various phases of the install with certain arguments (as documented in the Debian Policy Manual).
.deb vs .rpm differences?
dpkg-deb --fsys-tarfile uselessd_1.52.11_amd64.deb | tar tvf -
would enable examining the contents of the data archive and
dpkg-deb -I uselessd_1.52.11_amd64.deb postinst
would extract the postinstall configuration script to stdout.
.deb vs .rpm differences?
.deb vs .rpm differences?
.deb vs .rpm differences?
.deb vs .rpm differences?
.deb vs .rpm differences?
.deb vs .rpm differences?
.deb vs .rpm differences?
The dpkg-deb command can be used to do this.
.deb vs .rpm differences?
dpkg-deb -I <package.deb>
prints a summary of the package content which lists all scripts. A
dpkg-deb -I <package.deb> <script name>
can be used to show each of them.
Limiting the power of package installation in Debian
Limiting the power of package installation in Debian
Limiting the power of package installation in Debian
Yet, installing files is never going to be enough to integrate applications together. For example installing a plugin for a daemon that requires to run some kind of refresh command.
Limiting the power of package installation in Debian
Limiting the power of package installation in Debian
Limiting the power of package installation in Debian
Limiting the power of package installation in Debian
Limiting the power of package installation in Debian
I think the distribution model is somewhat outdated. It was great 20 years ago when the whole free software world fit on a single CD, they were written in C and disk space was at premium. Nowadays distributions just cannot cope with the huge amount of software out there. Debian has 20000 packages - this is about the same order of magnitude as the 8000 packages on hex.pm, but hex.pm hosts packages for niche languages Erlang and Elixir. PyPi has 157000 python packages, CPAN has 176000 perl modules, npm has 800000 JavaScript "building blocks" (that's 40 times the packages in Debian). Google Play has more than 3 million apps. It just doesn't scale a distribution to package everything, so it absolutely has to provide ways to install 3rd party packages. Also it's not feasible for the authors of these softwares to provide and maintain packages for various distributions in the official repositories of the distributions. They need not only generate the package, but be "part of the community" to be able to upload the packages to the official repository and it just won't happen.
Rant
Rant
Rant
Rant
Rant
Rant
I've seen the future and its the past.
What I do see is that distribution package management systems are increasingly relegated to simply setting up a base OS while other tools are used to manage most of the important software (from a perspective as a end user/developer/service provider) separate-but-on-top-of Linux distributions.
Not much change here: That's totally traditional "sysadminning" as it has been done since the 1980s (possibly even earlier).
Rant
Rant
Rant
Rant
Rant
Rant
Rant
Rant
> party packages.
I take issue with this comment:
don't install .debs from untrusted sources?
If you do not trust the .deb, then you should not be even installing it using dpkg, less running it unconfined, as its paradigm is based on fully trusting the .debs, on using shared resources, and on system integration.
That's not the reality of how software works out there. People *might* be able to run a vanilla Debian system without any third-party packages, but very often people are forced to install third party packages. In fact, we encourage that: don't we mock people who install software through curl | bash, pip, gem, or whatever? Don't we want all that stuff in Debian? For upstreams, this *will* mean providing their package as a PPA first, especially if they want to target users running stable. And those packages won't be vetter by a fellow Debian developer.
Not just Debian
* Providing macros for common scriptlets and generally offering means to hide scripetlets from packagers. This keeps packagers from needing to paste in random bits of shell code, and allows the macros to evolve or simply expand to nothing on releases where manual scriptlets are no longer needed.
Not just Debian
We would certainly like to get to a point where packages in the distribution simply don't have scriptlets. To the point that installing a package which does use scriptlets would be an exceptional act which could be flagged.
You will then end up in a state were upstream-sources will start to contain "global configuration scripts" of a few hundred lines of (obviously) Bourne shell code reconfiguring the system in prefectly arbitrary ways with prospective admin users being instructed to "just run that as root" after install (I've spent the better part of the last two weeks with packaging such a something for Debian/ Ubuntu) because
IOW, that's going to be a let of churn in order to end up exactly where things stand today.
Limiting the power of package installation in Debian
Limiting the power of package installation in Debian
Limiting the power of package installation in Debian
chmod 755 /usr/sbin/policy-rc.d
Limiting the power of package installation in Debian
Limiting the power of package installation in Debian
Limiting the power of package installation in Debian
Limiting the power of package installation in Debian
It may also sound/be installation person friendly which may make it easier to sell Debian as such.
But for the "I want to know what I do" faction, one has to stop the daemon immediately (or add some iptables rules beforehand) so that one can read and think about the configuration - let alone testing it.
Limiting the power of package installation in Debian
Limiting the power of package installation in Debian
Limiting the power of package installation in Debian
Limiting the power of package installation in Debian
Limiting the power of package installation in Debian
Many packages don't have that. Or install a server/daemon together with the client.
Limiting the power of package installation in Debian
Limiting the power of package installation in Debian
Limiting the power of package installation in Debian