ubuntu-phone team mailing list archive

[Alex Chiang <achiang@xxxxxxxxxxxxx>]

On Tue, Jan 14, 2014 at 2:21 PM, Jamie Strandboge <jamie@xxxxxxxxxxxxx> wrote:
> On 01/14/2014 03:11 PM, Chris Wayne wrote:
>> Hi Guys,
>>
>> So after looking at customizing powerd, I noticed several areas where we have
>> device-specific config files living inside deb packages.  As our idea of
>> customization has always been "one rootfs image for all devices", this seems a
>> bit problematic.  Just from a quick glance, I found the following
>> device-specific bits in the image (just a simple find / -name *maguro*):
>>
> ...
>
>> /usr/share/apparmor/hardware/graphics.d/apparmor-easyprof-ubuntu_maguro
>> /usr/share/apparmor/hardware/video.d/apparmor-easyprof-ubuntu_maguro
>
> FYI, apparmor-easyprof-ubuntu is currently shipping these itself, but that is
> temporary and are intended to be moved to lxc-android-config as per:
>
> https://lists.ubuntu.com/archives/ubuntu-devel/2013-September/037654.html
> https://bugs.launchpad.net/ubuntu/+source/lxc-android-config/+bug/1197133

I'm sorry I missed this discussion. That is my fault.

That said, I do have a few questions about option #3 in the proposal.

------------------------------
Pros:
 - allows packages to drop files into the apparmor include directory if
   they don't use udev (eg, nvidia)
[...]
 - works fine on read-only images
------------------------------

What does "works fine" mean? Meaning that once the policy files are in
place in an ro image, then apparmor DTRT?

How do packages install files into the new include directory if the
image is ro? Is this done at image creation time?

>> While this works for now with our limited set of supported devices, it can
>> quickly become untenable once we start building images for OEMs in the future,
>> or if we get an influx of community builds.
>>
> I figured that a necessary part of building up the port was building up the udev
> rules and apparmor accesses. OEMs/community builds would either fork
> lxc-android-config or work within the existing hierarchies to ship files in the
> appropriate directories. Both are shipped as debs and depart from the "one
> rootfs image for all devices" goal of course.

Speaking with Steve Langasek yesterday, I got strong guidance that all
per-device configs really need to live in the customization tarball.

And the customization tarball is only allowed to drop files into
/custom and $HOME.

>> I propose that we try and tackle this before it becomes a problem.  Do we have a
>> plan for this already?
>>
>> If we don't have a plan quite yet, as a first step, I propose that we patch
>> powerd and apparmor to look in XDG_DATA_DIRS instead of just /usr/share/ for its
>> configs.  If we do this, we can drop any needed configs into a custom tarball
>> (which includes /custom/xdg/data, which is included in XDG_DATA_DIRS), and
>> therefore keep the rootfs as device-agnostic as possible.  Does this seem
>> reasonable?
>>
> Even if it could be done easily (which it can't), we won't patch apparmor to
> honor an environment variable like this. It could potentially allow apparmor to
> read user controlled files which could then be used to break out of confinement.
> What is easy and fine with me once we define where they should live is to add
> the #include directory for something in /custom/xdg/data (this directory could
> be adjusted via an apparmor tunable of course, if we wanted to go that route).

Compile-time #include over run-time environment variable is fine. It's
the configurability of the path that we care about.

Thanks.