Use Cases, Issues, Proposed Solutions: Software and Environment Non Privileged User Package Management Francois-Denis Gonthier Kryptiva inc. Steven Pigeon Département de Génie Logiciel et des Technologies de l’Information (ETS)

Issues of system installs Users depends on Administrators – Annoys administrators Users install packages themselves – Problems with Dependencies – Problems with Security – Problems with Redundancy

Objections Policies Redundancy Automatic Updates Security “Root” packages Sudo Delegation “sudoers”

Policies Users may lack essential skills – May or mayn't be familiar with Linux – Are often oblivious of other users Users ignore any policies they can

Redundancy If users each install their packages from tarballs – Many copies of the same may be found – No simple means of pooling installs

Automatic Updates Packages installed by users – May or mayn't be of the correct version for the current install – Are not automatically updated with the rest of the system

Security If users each install their packages from tarballs – They can install software from unauthenticated repositories – They can install software from incompatible repositories

“Root” Packages Some packages are inherently “root” – Kernel modules (and drivers) – Applications and services with restricted ressources usage

Sudoers Delegating Installs using “sudoers” – Basically gives root access to users – Malignant users can modify global configuration – Users can install broken or malicious packages from unauthenticated sources

Alternatives? Sudo Delegation “sudoers” – Already shown to be bad PackageKit Vserver (... or virtual machines)

What is PackageKit? ● Priviledged dbus service ● Uses distributor backend Conary RPM Apt PackageKit App. Dbus & PolicyKit

PackageKit Good Allow users to install software Potentially supports policies and filtering Bad No protection against bad packages... or bad users

What is Vserver? ● Isolated Linux instances ● Shared kernels (Vserver)... or not (VMs) Host machine Guest

Vserver Good Total control by user Isolation Bad Ressource cost Heavy redundancy Recursive problem

Proposed Solution Unprivileged User Installs Relocatable packages Multiple package databases Environment setup

Relocatable Packages Currently, package relocation – Partially supported by RPM – Breaks maintainers scripts Package content must be made relocatable Maintainer script be must be aware of new location

Multiple databases Currently, package database – Writable by root user only – Multiple database are not supported Must be accessible to user “Merged” with the system database

Relocatable packages File relocation (prefix based) Maintainer scripts support Software – Use relative paths – Environment variables

Multiple databases Package database local to user (or group) Local database “linked” with system database – Aware of system-installed dependencies – Make local version override possible

Setting Up Software Environment Environment setup – Prepare the software environment – Run all package specific initialization Executed through – PAM – Traditional session-initialization script

User package install 1. Reads local database 2. Reads system database 3. Merges both database 4. Resolves dependencies

System package install 1. Reads system database 2. Reads all user databases 3. Resolves dependencies Query for confirmation in case of conflicts Uninstall user-package if needed 4. Installs system packages

Dependencies, conflict resolution General rule – System package rule over user package – Might uninstall user packages (with confirm.) – Refuse to install non-relocatable package User – Can install earlier/other compatible versions

Repository policies Repository management – Allow/disallow custom repositories – White/black list of repositories – Distribution-specfic white/black list

Install policies Filters – By package “tags” (ie: exclude games) – By sections – Regular expressions – etc.

Modification to existing Package Management Software Development tools Maintainer scripts Database format (name, location) Conflict resolution Apt changes

Development tools Automate repetitive tasks – Setup common binary paths –... library paths –... manual paths... and that is all that is needed in some case

Program changes Relative path – FHS hierarchy –... relative to the program location

Maintainer scripts and conflict resolution Maintainer scripts – Must be made aware of location Conflict resolution – Rules already explained

Apt/Dpkg Read user database Handle policies – Apply policy before downloading – Support repository policies –... install policies

Conclusion Useful Nothing really impossible Can be made stable Little modifications needed in some case