[OE-core] Directory permissions and ownership -- RFC

[Mark Hatle]

I've had the task to resolve the directory permissions and ownership issues.
>From the original RFC I sent out, a lot has changed.

The way OE, opkg and deb packages are defined, there is no way to define what
package "owns" a directory.  There is an expectation that directory permissions,
owner and group are consistent between packages (and thus recipes).

I've worked though a number of the issues.  While I'm not posting the patches
yet for inclusion, I'd like some feed back on the two specific patches below.

Patch 1:

Adjust the umask to 022.  This resolves the problem of dynamically generated
directories (mkdir -p) and specific files (touch foo) having odd permissions.

http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=mhatle/perms&id=d8470b6a8efdbba04cef5d4dc1ce12720fe83621

Patch 2:

The item adds a new step to the package.bbclass, fixup_perms.  The function that
is responsible for fixing directory and file permissions, owners and groups
during the packaging process. This will fix various issues where two packages
may create the same directory and end up with different permissions, owner
and/or group.

The issue being resolved is that if two packages conflict in their ownership of
a directory, the first installed into the rootfs sets the permissions. This
leads to a least potentially non-deterministic filesystems, at worst security
defects.

The function has a set of default values. We sanitize all of the system
directories, as defined in bitbake.conf as 0755, root, root. We also have
determined as series of documentation directories. These are sanitized as 0755,
root, root with the files they contain as 0644, root, root. The user can add
their own settings, or override the defaults by providing a
meta/files/fs-perms.txt file. The format of this file is described in the
default file.

http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=mhatle/perms&id=eb76974fb73f2793e9d6191fb12d502fefc74c80


Any comments/feedback is appreciated.

--Mark