GSoC/2022/StatusReports/SuhaasJoshi

Introduction

Project Overview

In Linux, applications are installed as packages. A package is a set of files that contains the application's executable, version, metadata etc. Distributions have different packaging formats, and different release cycles. These differences need to be accommodated by developers.

Flatpaks and Snaps are distribution-agnostic methods of installing and maintaining software. They contain all the dependencies necessary for running the application, independent of the distribution's native copy of them.

As a security feature, applications packaged in these formats do not enjoy full access to system resources, unlike traditionally packaged applications. These applications have to be granted permissions to access the majority of features of the system.

These permissions are usually granted at the time of packaging, but the user is free to grant, revoke and modify these permissions as per their preferences. While there exist command-line options granted by Flatpak and Snap tools respectively to change these permissions, KDE lacked system settings modules to do so graphically. Further, some of these permissions are technical and would be unfamiliar to many users.

My Goal during GSoC: My project entailed the creation of system setting modules to allow the user to graphically change their permissions.

How Flatpak Manages Permissions

Flatpak applications store their default permissions (that is, those that are granted by application developers at the time of packaging) in their metadata files. When these permissions are changed, the changes (name of the permission and the change introduced) are written to the application's overrides file (named the same as the ID of the application). Applications, during execution, are granted permissions as per the specifications of this file.

There are different types of applications: some have only an on/off value, while others have more options: filesystem permissions, for instance, can have values from among "read-only", "read/write" and "create". Further, users may be able to add specify filesystems, buses and environment variables that were not originally listed.

I have elaborated in more detail on concepts surrounding this part of the project in this blog post.

How Snapd Manages Permissions

To allow Snapd applications to access resources outside their sandbox, there exist interfaces. Packages are granted access to these interfaces, as required. This would include access to certain files and directories, or hardware devices such as webcams.

Snaps use interfaces by declaring themselves as plugs for those interfaces. Interfaces are provided by slots. Upon declaration of the interfaces required, these plugs are connected to the required slots.

Snapd Qt API provides methods to set the values for these permissions.

Links to the Code Written

The code for Flatpak and Snap KCMs is written in their own, separate repositories. These repositories were created for the GSoC project, and all the code written in them is my GSoC work.

Flatpak KCM: https://invent.kde.org/plasma/flatpak-kcm

Snap KCM: https://invent.kde.org/jsuhaas/snapkcm

Project Status

Flatpak KCM

At this point, the following are accomplished:

1. The KCM loads all the applications and their details, and lists them.
2. Permissions are loaded, with relatively easy-to-understand descriptions.
3. Permissions can now be added, modified and revoked.
4. Users can grant access to new filesystems, session and system buses and specify environment variables not originally listed in the metadata.
5. The UI is split into basic and advanced section, which was a design goal since the beginning.

Thus the KCM is currently in usable state.

What's left: Presently we are in the process of moving the repository from my personal namespace to Plasma group, and thereby releasing it to users. This includes:

1. running clang-tidy/clazy tools on the repository.
2. implementing any minor suggestions that are made.
3. requesting a bugzilla product.

Snap KCM

The following are accomplished:

1. all the applications and their details are loaded and listed
2. the permissions for applications are listed
3. the permissions can be changed by the user

What's left: Snap permissions are simpler than Flatpak ones in the sense that they contain only ON/OFF values, and do not allow the addition of filesystems, session and system buses etc. The following goals are left:

1. implementing functionality of the "Apply" button (currently, permissions are directly changed without waiting for the user to confirm the changes)
2. beginning the process of moving it to the Plasma group

Blog Post Links

• https://jsuhaas22.github.io/devblog/jekyll/update/2022/06/14/gsoc-post-0-introduction.html
• https://jsuhaas22.github.io/devblog/jekyll/update/2022/07/21/gsoc-post-1-flatpakkcm-update.html
• https://jsuhaas22.github.io/devblog/jekyll/update/2022/09/05/gsoc-post-2-flatpakkcm-update-2.html

Post-GSoC Plans

GSoC has been a wonderful experience, full of incredible learning and new exposure. The KDE community has been very welcoming and helpful. I intend to continue developing and maintaining these system settings modules, and see myself contributing to Discover, Okular and other KCMs. More specifically, in the immediate future, I intend to:

1. finish letting users change their Snap permissions, and moving that module to the Plasma group
2. implement some additional features on Flatpak KCM, such as giving users an option to remove applications from them