Running on real hardware...

Tue Dec 16 00:00:24 UTC 2014

ooops :)...

was trying to say, you can find docs how to manually hack the
confinement of your local snappy app here:

https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement

To get something going quickly you can select unconfined template for
your binaries/services.

Once stuff is up and running you can see how you can punt holes into
our default template instead of going fully unconfined. I think the
wiki has most info you will need.

On Tue, Dec 16, 2014 at 12:54 AM, Alexander Sack <asac at canonical.com> wrote:
> On Tue, Dec 16, 2014 at 12:21 AM, Dan Kegel <dank at kegel.com> wrote:
>> The target app uses modern OpenGL heavily, and also uses X.
>> It's probably beyond the scope of my exercise to try porting the app
>> from X to Mir or Wayland.
>>
>> As long as I can still use X and OpenGL, and have control over which
>> version of the official proprietary ATI/Nvidia drivers are in use,
>> I don't care if Mir is there, too.  Well, depending on performance,
>> I guess.  The compositor might hurt benchmarks.  (I'm at the edge of
>> my knowledge here.)
>>
>> The use case is essentially "chromeos", i.e. a system that boots into
>> a web browser
>> and autoupdates silently, as an exercise to see if it can be done.
>> A more real-world use case is "arbitrary graphics-intensive
>> autoupdating appliance",
>> where there is exactly one OpenGL app (for instance, a media player),
>> so I'm not at all worried about crosstalk between apps,
>> but I am interested in stability and efficient/safe autoupdating.
>> In neither case is any kind of OS UI exposed to the user, it's all app ui.
>
> Allright, in that case I wouldn't bother about framework nor  pumping
> up the system base. Instead try to put everything together in your
> snapp as one big bundle.
>
> Would be interesting to see what the most minimal confinement holes
> you have to punt into our default confinement template:
>
>
> I think it's likely that you will hit some apparmor barriers that will
> prevent this from working, but once you hit that issue come back with
> the logs stating the apparmor denies and we can see how you can
> manually punch very carefully crafted holes into snappy confinement.
>
>
>
>> - Dan
>>
>> On Mon, Dec 15, 2014 at 2:55 PM, Alexander Sack <asac at canonical.com> wrote:
>>> Hi Dan!
>>>
>>> very interesting things you are exploring here :)...
>>>
>>> below more detailed input, but before I wonder if you have a specific
>>> use case in mind that made you try this?
>>>
>>> On Mon, Dec 15, 2014 at 2:13 AM, Dan Kegel <dank at kegel.com> wrote:
>>>> Haven't gotten nvidia working yet, but here's a recipe that at least lets
>>>> you run 'sudo startx' and get an X terminal using vesa.
>>>>
>>>> 1) on a throwaway vm, install a 15.05 daily, then do
>>>>
>>>> pkgs="
>>>> libc6
>>>> libevdev2
>>>> libfontconfig1
>>>> libfontenc1
>>>> libice6
>>>> libmtdev1
>>>> libpciaccess0
>>>> libpixman-1-0
>>>> libSM6
>>>> libtinfo5
>>>> libutempter0
>>>> libx11-6
>>>> libx11-xcb1
>>>> libxau6
>>>> libxaw7
>>>> libxcb1
>>>> libxdmcp6
>>>> libxext6
>>>> libxfont1
>>>> libxft2
>>>> libxkbfile1
>>>> libxmu6
>>>> libxmuu1
>>>> libxpm4
>>>> libxrender1
>>>> libxshmfence1
>>>> libxt6
>>>> nvidia-304
>>>> nvidia-331
>>>> x11-common
>>>> x11-xkb-utils
>>>> xauth
>>>> xbitmaps
>>>> xinit
>>>> xkb-data
>>>> xserver-xorg
>>>> xserver-xorg-core
>>>> xserver-xorg-input-evdev
>>>> xserver-xorg-input-kbd
>>>> xserver-xorg-input-mouse
>>>> xserver-xorg-input-void
>>>> xserver-xorg-video-nouveau
>>>> xserver-xorg-video-vesa
>>>> xterm
>>>> "
>>>> rm -rf staging
>>>> mkdir staging
>>>> cd staging
>>>> apt-get download $pkgs
>>>> for pkg in *.deb
>>>> do
>>>>     dpkg-deb -x $pkg .
>>>> done
>>>> tar -czvf x.tgz usr etc
>>>>
>>>> 2) transfer x.tgz to the Core system,
>>>> remount / read-write,
>>>> unpack into /,
>>>> put 'xterm &' in ~/.xinitrc
>>>> sudo startx
>>>>
>>>> I also had to add video modes to /etc/X/xorg.conf, but that's probably just
>>>> my crappy monitor.
>>>>
>>>> That's an awful lot of bytes just to run X.  Presumably a real use
>>>> would whittle that
>>>> down and pickle just the minimal amount needed for your app (possibly
>>>> remounting using atime, or tracing using strace, to see which files
>>>> are really needed
>>>> during a full run of the app).  And then there's the whole question of
>>>> how to build a custom version of Core that includes these files,
>>>> and lets you build a delta update stream for the custom system...
>>>
>>> Hmm...
>>>
>>> the official approach to extend a snappy system is NOT by adding stuff
>>> to our system-image; instead, snappy systems are extended through a
>>> special type of .snap package: FRAMEWORKS. Frameworks allow you to
>>> extend the base-system for apps that use it. Unfortunately, our docs
>>> don't explain this concept very well right now as we wanted to first
>>> focus on seeing how far apps can go without extending the base system
>>> (e.g. through bundling etc.).
>>>
>>> Depending on what you are after, making X11 available part some
>>> framework should be doable, but be warned that in almost all cases the
>>> real challenge will be to make X11 behave securely so that other
>>> snapps don't end up getting hacked and highjacked by other evil
>>> snapps.
>>>
>>> As a sidenote, if you are just looking at something that powers a GL
>>> apps, maybe check if using MIR might be a valid alternative. I assume
>>> that's not an option?
>>>
>>> Hope that helped a bit. Let us know how things go!
>>>
>>>  -  Alexander
>>>
>>> p.s. for more info about frameworks, search for "frameworks" on
>>> ubuntu.com/snappy. WRT to examples: the current only (and far from
>>> complete) example of a framework is docker on snappy-hub: bzr branch
>>> lp:~snappy-dev/snappy-hub/docker - I am also around on #snappy IRC for
>>> more interactive chat.