Multi-db /var/lib/rpm and /var/lib/appstore isolation skeleton #40

Closed
wants to merge 6 commits into
from

Projects

None yet

5 participants

@xiangzhai

RPM Next

RPM Next Multi-db /var/lib/rpm and /var/lib/appstore isolation skeleton implementation.

Background

One day Cjacker had an idea: there are OS layer (/var/lib/rpm) and AppStore layer (/var/lib/appstore) physical isolated. so rpm -ivh/-e only install/erase Apps into/from AppStore layer, OS is totally READ-ONLY. when installing Apps, check dependency in OS layer at first, if unsatisfied depend, then switch to AppStore layer for checking dependency again, if still unsatisfied depend, add dependency problem, otherwise installed Apps successfully.

NOT container

It is NOT xdg-app nor limba, but multi-db isolation try to forbid 3rd-party App pollute the core components of operating system.

Goal

  • keep rpm original command unbroken;
  • keep librpm original API unbroken;
  • just like Mac _make install_ is still able to pollute OS layer.

Regards,
Leslie Zhai

xiangzhai added some commits Dec 28, 2015
@xiangzhai xiangzhai Update README f8cb836
@xiangzhai xiangzhai Add a very simple testcase for verifing the implementation.
Cjacker has a very sophicated and full testcase script, please feel free to ask him ;-)
3ce56b6
@xiangzhai xiangzhai Update README 8584534
@MingcongBai

Someone fix this Chinglish mother load...

;P

@Artoria2e5

Well, I think we should purge all README changes…

Let me make this look like something sound first.


RPM with overlay-ish multi-db support

On some commercial-ish (or modern according to $$$ OS users) distros like iSoftLinux, on which @xiangzhai and @cjacker (who came up with the original idea) are currently working, the OS-layer core packages and the 'App Store' are largely isolated. In iSoft's case, it's physically separated, with the OS used just like something read-only. Therefore this leads us to two main changes:

  1. rpm -ivh and rpm -e should only do operations on App Store's db. No changes will be done on the system db, so we can further avoid cavities and having to go to a dentist [note 1]. This may stop weird foreign RPM packages by nasty big Chinese Internet companies from messing up the system RPM db.
    • make install will still be able to pollute the system if the user can write into system things. This is not what iSoft is trying to stop.
  2. When searching for dependencies, rpm should first search in the OS db, then try the less trusted AppStore db, and finally as usual, add a not satisfied problem if it can't find the dep.

The goal, again as usual, is to make both the command line rpm program and the librpm API backwards compatible (according to the README but well I have spotted one API change already), or iSoftLinux will have to release something like RPM 5 (wait is that name already taken? oh RPM Next sounds like a nice name) to make Semantic Versioning lovers happy.

For now the App Store is simply located at /var/lib/appstore. Perhaps Apple will be unhappy with this.

Notes

  1. "Our goal is to have no cavities!" is just a random popular Chinese Colgate AD slogan. Nobody knows why it got popular, but everyone just keeps saying “我们的目标是——没有蛀牙!”.

Hey xiangzhai, db6 is released under AGPL. Nobody knows why Oracle did that but you might want to keep using db5. Can you test compiling your thing with db5?

@xiangzhai

For now the App Store is simply located at /var/lib/appstore. Perhaps Apple will be unhappy with this.

+1

Hey xiangzhai, db6 is released under AGPL. Nobody knows why Oracle did that but you might want to keep using db5.

Berkeley DB is really difficult to use, there are sophisticated Wrapper and Controller Interface for rpm usage.

I prefer to use SQLite3, so I totally rewrote the pkgcache generation for APT-RPM, it is quite simple to use SQLite table to store Package information about _Requires_ and _Provides_ for Building Dependency Tree ;-)

CREATE TABLE `Package` (
    `Name`  TEXT NOT NULL UNIQUE,
    `Version`   TEXT NOT NULL,
    `Release`   TEXT NOT NULL,
    `Arch`  TEXT NOT NULL,
    `IGroup`    TEXT NOT NULL,
    `Uri`   TEXT NOT NULL,
    `Requires`  TEXT,
    `Provides`  TEXT,
    `Md5`   TEXT,
    `Status`    INTEGER NOT NULL DEFAULT 0
);
@ffesti
Contributor
ffesti commented Feb 18, 2016

We'll twice a year someone comes up with some sort of dual/multiple rpmdb proposal. None of them so far got beyond answering the first main questions:

What's the use case? Would that actually work? Isn't this really the right solution to this problem?

Which typically go into some more detailed questions like:

If the system is readonly what about updates?
If the system is not read only what happens if updates are not compatible/in sync with the secondary database?

If you want to protect you system packages there are probably easier ways to do - depending what you are actually trying to defend against. Rogue admins? Badly build packages? Broken dependencies?

May be implementing repository pinning on the depsolver level (yum/dnf) is much more helpful for this. Or pinning the system packages - either with an rpm plugin or an yum/dnf plugin - or by adding a system meta package requiring the exact versions of all system packages.

Depending of what you exactly what to do these option are much easier to get implemented.

@xiangzhai

What's the use case? Would that actually work? Isn't this really the right solution to this problem?

For the Mac-alike close system, it provides System Update Daemon and rpm command

If the system is readonly what about updates?

There is System Update Daemon use original RPM API to update /var/lib/rpm

If the system is not read only what happens if updates are not compatible/in sync with the secondary database?

Just like Mac, when system update broke the dependency in the /var/lib/isoftapp, System Update Daemon will mark the broken APPs, then users might find other APPs' rpm packages.

@dnf-bot
dnf-bot commented Apr 22, 2016

Can one of the admins verify this patch?

@dnf-bot
dnf-bot commented May 13, 2016

Can one of the admins verify this patch?

@ffesti
Contributor
ffesti commented Jun 2, 2016

I really can't see this changes going in upstream. Beside the duplication of a lot of code, duplication of the API there are lots of unresolved - probably even unnoticed - issues. Including but not limited to:

  • Support in dependency solvers
  • UI
  • Update requiring changes in both DBs
  • Obsoletes matching packages from both DBs
    There are also serious doubts whether the added complexity really lowers the overall risks.
@ffesti ffesti closed this Jun 2, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment