Integrate apt-get with xdg-app
SuicSoft opened this issue · 25 comments
I would like to integrate xdg-app with apt-get so that software center apps they can be run in the sandbox.
I'm not sure what you mean. Do you want to run apt-get in a sandbox? That can't work, it has to modify the host system.
@alexlarsson Maybe we can install the packages in to ~/.local (see http://askubuntu.com/questions/339/how-can-i-install-a-package-without-root-access) and then run them in the sandbox
@alexlarsson Have you seen this?
You can install xdg-app packages as a user, without root. But that can't automagically install deb packages, as it is something completely different.
Could you use debian packages to create xdg-app bundles? Probably, but it would have nothing to do with apt-get, nor would it involve modifications to xdg-app.
Anyway, I'm closing this issue because I don't see how it really affects xdg-app at all.
@alexlarsson How about a tool to convert debian packages to xdg-app.
Then maybe I can write my own apt-get and dpkg which converts the .deb package toxdg-app using the tool and installs it
@SuicSoft If you had a runtime based on the debian package sets you could then convert dpkg apps to xdg-apps. However, xdg-apps need to be built with a different prefix (/app) so you likely will have to rebuild them from source.
@alexlarsson Where are the xdg-apps stored?
https://wiki.gnome.org/Projects/SandboxedApps has some descriptions on how things are stored
@alexlarsson So it there any way to change the prefix without compiling? It would be hard to setup a development environment just to install a package
Some software are relocatable (without rebuilding), some are not.
@alexlarsson How do you relocate. Do you move the files or what.Maybe some software have hard-coded file locations which could not be changed but maybe we could chroot or something
Relocation is a tricky problem, some software have custom solutions that allow it, some don't. There is no generic way to do it other than rebuilding. For technical reasons we require apps to be built in /app, and there will be no magic solution that makes this easy to fix. If there were xdg-app would not have this requirement.
I'm also rather confused by this. I thought that xdg-app used some sort
of containers. But the container solutions I know, like LXC, Docker ect.
all are extremely flexible and let you use whatever package manager you
like and allow you to place the binary where-ever you want. What
technical reason do you have for this limitation?
On 03/22/16 09:34, Suici Doga wrote:
@alexlarsson https://github.com/alexlarsson How do you relocate. Do
you move the files or what.Maybe some software have hard-coded file
locations which could not be changed but maybe we could chroot or
something—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#113 (comment)
@alexlarsson So I would like to know the steps to relocate a simple app like cowsay. Do you just use the cowsay files with https://blogs.gnome.org/alexl/2016/02/19/building-an-xdg-app-part-2/ ?
@timthelion Do container solutions have a sandbox ?
Do containers have a sandbox? Well, containers contain, or at least they
should. So yes, they do have a sandbox...
On 03/22/16 09:41, Suici Doga wrote:
@alexlarsson https://github.com/alexlarsson So I would like to know
the steps to relocate a simple app like cowsay. Do you just use the
cowsay files with
https://blogs.gnome.org/alexl/2016/02/19/building-an-xdg-app-part-2/ ?@timthelion https://github.com/timthelion Do container solutions
have a sandbox ?—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#113 (comment)
@alexlarsson Is the reason for requiring the programs be in /app to
allow for your runtimes to be in another folder and to prevent conflicts
along the way?
On 03/22/16 09:41, Suici Doga wrote:
@alexlarsson https://github.com/alexlarsson So I would like to know
the steps to relocate a simple app like cowsay. Do you just use the
cowsay files with
https://blogs.gnome.org/alexl/2016/02/19/building-an-xdg-app-part-2/ ?@timthelion https://github.com/timthelion Do container solutions
have a sandbox ?—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#113 (comment)
@timthelion Can they prevent access to hardware like the webcam or the internet
@timthelion
xdg-app is not a container system. Container systems have a major focus on constructing your own custom containers (because every user creates his own containe). xdg-app is a desktop application shipping system, and the users of it consume pre-build applications in a read-only way.
Thus, rather than having a layered system like docker, with all its complexities we have a simple hardcoded split between runtime and applications. This allows these two to be completely separate and evolve on themselves. For example, the runtime (/usr) can get a security update without affecting the app (in /app) or requiring a new version of the app. For instance, the runtime can add a file without risk of it being deleted in the "app layer".
Also, not having a layering system vastly simplifies the machinery, which is what allows xdg-app to run without root privileges.
@alexlarsson So about instructions for converting a simple app like cowsay or fortune
I know both endless (https://endlessm.com/) and simon (debian packager of xdg-app) have created xdg-app from debian packages. Its possible, but its not something i'm interested in spending a lot of time writing about in a bug tracker. Nor am i in any way an expert on debian packaging. In fact I'm rather poor at it.
For a simple app like those you can probably follow part 1 of the tutorial though.
@alexlarsson I am going to try https://smcv.pseudorandom.co.uk/2016/xdg-app/ and maybe write a Python script to do this.Then I could maybe modify the dpkg to install packages using the script (I do not know C++ very well but I should be able to do it).
And also just thinking if xdg-app can show a dialog asking for permission when an app tries to do something that is restricted in the metadata (this can happen if a user saves a file to a FTP server in a app).
Even when using the method in the link we will have the prefix problem. Is there anything you could do to change the prefix at runtime of the application
@alexlarsson I asked a question on UNIX & Linux StackExchange.The link is https://unix.stackexchange.com/questions/272046/is-it-possible-to-change-the-prefix-of-an-application-without-recompiling and upvote if you have a StackExchange account :)
@alexlarsson Probably if you can change the prefix of the application by hooking functions (like an LD_PRELOAD library). A list of the functions needed to be hooked can be found in the checkinstall source code.
Heres something like that I was working on a while ago https://github.com/ProjectPolyester/libmove/blob/master/libmove.c. I will add something like that to Flatpak (formally xdg-app) if i know where to add it.
Then you should be able to create Flatpak packages out of Debian binaries.
We can't just rewrite all /usr references, all the references to things in the runtime should still be in /usr. Also, rewriting like this is extremely fragile and limited, so I'm not very interested in it as a general solution.