the case of a sandboxed server application

[Nils Gillmann]

How do we handle applications which absolutely need to write in
their data folders?

Is there some case like psyced which I could refer to for
packaging and service creation later when I package psyced, or is
this a first one for psyced?

Psyced comes with its own sandbox, and it needs this access.
The following chatlog is posted with permission, and any input on
how to do this (currently low priority) packageset would be
welcome, or some packages I could look at to compare.

If it's not possible with guix currently, I think we need to fix
it as psyced will not be the only software behaving like this as
a security feature.

2016-04-01 10:33:27     lynX    [10:02] ng0 sagt: lynX: urgh. can you include 
some statement like that git checkout is now the prefered method and future 
tarball releases are unlikely or whatever on the psyced.org
2016-04-01 10:33:27     lynX    [10:02] ng0 sagt: website? seems like guix 
wants this.
2016-04-01 10:33:27     lynX    [10:03] psyced already uses git for updates 
(see psyced -u)
2016-04-01 10:33:27     lynX    [10:03] its only the first install.sh thati'm 
not sure is ready to go to trash
2016-04-01 10:33:27     lynX    [10:03] and install.sh only works from tarball
2016-04-01 10:33:27     lynX    [10:04] my last test install i did from psyconf 
only
2016-04-01 10:33:27     lynX    [10:04] thus the recent edits of psyconf
2016-04-01 10:33:27     lynX    [10:05] a packaged psyced should not run 
install.sh methinks.. that's for starting from zero knowledge
2016-04-01 10:33:27     lynX    [10:06] and it stems from the days when servers 
were using sun or irix

2016-04-01 10:39:28     ng0     I would also have to come up with a solution 
for a psyced system configuration and service in guixsd because it just can't 
use psyced -u the way it normaly does
2016-04-01 10:40:11     lynX    that's easy, just run psyconf after git pull
2016-04-01 10:41:17     ng0     how if you(the service user) will have no write 
access to the directories (at least from what I know in theory from guix, I 
might be wrong about this)
2016-04-01 10:41:51     ng0     psyconf will have to be part of sys config
2016-04-01 10:43:35     lynX    i presume git pull also runs as admin, no?
2016-04-01 10:43:50     lynX    both are safe to run as root
2016-04-01 10:49:04     ng0     it's not about being safe to run, the store 
just can't be altered. put the config in a writeable location, good, but 
/gnu/store/ just won't work. if it is part of the
2016-04-01 10:49:04     ng0     systemconfig and it can be changed through it, 
it will work. otherwise it has to live in for example /etc/psyced/config 
instead of
2016-04-01 10:49:04     ng0     /gnu/store/hashp-syced-version/opt/psyced/config
2016-04-01 10:50:12     ng0     i have no idea how webservers are configured 
here at the moment, but I assume it's a combination of both
2016-04-01 10:50:43     lynX    the config goes into /etc/psyc usually
2016-04-01 10:50:57     lynX    and that is for the admin to edit manually... 
which eans you can generate it
2016-04-01 10:51:14     lynX    the stuff in /opt needs to be writeable because 
psyced is a sandbox
2016-04-01 10:51:23     lynX    you can put it in /var if that sounds better to 
you
2016-04-01 10:51:40     lynX    but psyced cannot be read-only .. and its not a 
bug, its a feature
2016-04-01 10:51:45     ng0     oh. so then just the psyced -u will be broken 
and if there's a systemservice it can go into either manual file option 
(/etc/psyc/) or systemservice (/gnu/store/ location
2016-04-01 10:51:47     lynX    psyced runs in a sandbox
2016-04-01 10:52:09     lynX    if you install psyced into /var, then psyced -u 
isnt broken
2016-04-01 10:52:52     ng0     hm.. i have to learn more about both psyced and 
guix to know if this is okay, but i assume just putting things outside of the 
store will not work
2016-04-01 10:53:12     lynX    where do tools put their logs?
2016-04-01 10:53:16     lynX    and data?
2016-04-01 10:53:19     ng0     /var/log/
2016-04-01 10:53:26     ng0     datafiles into store
2016-04-01 10:53:37     lynX    consider psyced source as data
2016-04-01 10:54:20     lynX    you could also do something with symlinks to 
only make data, place and log writable
2016-04-01 10:54:25     ng0     i could install some software which behaves the 
same way and see how it was decided upon to do
2016-04-01 10:55:17     lynX    dont know of other sandboxed servers
2016-04-01 10:55:34     lynX    android emulator maybe

2016-04-01 11:15:13     ng0     irc servers don't act similar?
2016-04-01 11:16:19     lynX    irc servers have no state
2016-04-01 11:16:53     lynX    and they have no sandbox

2016-04-01 11:18:46     ng0     to my knowledge, something which behaves like 
psyced is not packaged at this point.
2016-04-01 11:21:39     lynX    see stuff that does chroot.. although psyced 
doesnt really chroot

2016-04-01 11:27:04     lynX    or does guix presume all software to be bug 
free ;)
2016-04-01 11:27:49     lynX    you can completely hack a psyced and still not 
get access to unix prompt... merit of a sandbox
2016-04-01 11:27:57     lynX    if you hack an ircd, you are root
2016-04-01 11:29:25     lynX    we never had a security incident in.. er.. 
almost 30 years of lpc server service
2016-04-01 11:32:11     ng0     :) no idea.. core devs might have an idea on 
this. may I send some of the logs or summary via email to the list if I need 
further input on how to handle psyced?

2016-04-01 11:33:52     lynX    what list?
2016-04-01 11:34:14     ng0     guix-dev mailinglist, if I need more input from 
for example ludovic
2016-04-01 11:34:37     lynX    you mean chat logs?
2016-04-01 11:34:58     ng0     snippets of it, describing how psyced works.
2016-04-01 11:35:14     ng0     or just not sending it and just describing what 
you described
2016-04-01 11:35:16     lynX    yup


-- 
ng
personal contact: http://krosos.sdf.org
EDN: https://wiki.c3d2.de/EDN