Patchwork [0/2] Ensure a reasonable umask, and fix up permissions (V2)

login
register
mail settings
Submitter Mark Hatle
Date June 27, 2011, 3:26 p.m.
Message ID <cover.1309188064.git.mark.hatle@windriver.com>
Download mbox
Permalink /patch/6529/
State New, archived
Headers show

Pull-request

git://git.pokylinux.org/poky-contrib mhatle/perms

Comments

Mark Hatle - June 27, 2011, 3:26 p.m.
Revised the fixup_perms function in package.bbclass.  Change to using a
class based approach for the individual permissions entries.

Add support for directory linkages.

Add entries to match base-files recipe in the fs-perms.txt.

(umask commit is unchanged, resending due to time since last sent)

----

V1 log below

Add a new 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 user can specify their own settings via the configuration files
specified in FILESYSTEM_PERMS_TABLES.  If this is not defined, it will
fall back to loading files/fs-perms.txt from BBPATH.  The format of this
file is documented within the file.

By default all of the system directories, specified in bitbake.conf, will
be fixed to be 0755, root, root.

The fs-perms.txt contains a few default entries to correct documentation,
locale, headers and debug sources.  It was discovered these are often
incorrect due to being directly copied from the build user environment.

Also tweak a couple of warnings to provide more diagnostic information.

The following changes since commit 0009fa951d45c742963279b0d9740c1209b46456:

  linux-firmware: Fix file permissions (2011-06-24 13:32:21 -0500)

are available in the git repository at:
  git://git.pokylinux.org/poky-contrib mhatle/perms
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=mhatle/perms

Mark Hatle (3):
  Add umask task control
  classes/package.bbclass: Add fixup_perms

 meta/classes/base.bbclass                          |    4 +
 meta/classes/image.bbclass                         |    2 +
 meta/classes/package.bbclass                       |  253 +++++++++++++++++++-
 meta/classes/staging.bbclass                       |    1 +
 meta/files/fs-perms.txt                            |   69 ++++++
 .../installer/adt-installer_1.0.bb                 |    2 +
 meta/recipes-kernel/linux/linux-tools.inc          |    2 +
 7 files changed, 346 insertions(+), 14 deletions(-)
 create mode 100644 meta/files/fs-perms.txt
Koen Kooi - June 27, 2011, 3:31 p.m.
Op 27 jun 2011, om 17:26 heeft Mark Hatle het volgende geschreven:

> Revised the fixup_perms function in package.bbclass.  Change to using a
> class based approach for the individual permissions entries.
> 
> Add support for directory linkages.
> 
> Add entries to match base-files recipe in the fs-perms.txt.
> 
> (umask commit is unchanged, resending due to time since last sent)
> 
> ----
> 
> V1 log below
> 
> Add a new 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 user can specify their own settings via the configuration files
> specified in FILESYSTEM_PERMS_TABLES.  If this is not defined, it will
> fall back to loading files/fs-perms.txt from BBPATH.  The format of this
> file is documented within the file.
> 
> By default all of the system directories, specified in bitbake.conf, will
> be fixed to be 0755, root, root.
> 
> The fs-perms.txt contains a few default entries to correct documentation,
> locale, headers and debug sources.  It was discovered these are often
> incorrect due to being directly copied from the build user environment.
> 
> Also tweak a couple of warnings to provide more diagnostic information.

Does this rely on the umask feature in bitbake master? If so, we should check the minumum bitbake requirements again
Mark Hatle - June 27, 2011, 3:34 p.m.
On 6/27/11 10:31 AM, Koen Kooi wrote:
> 
> Op 27 jun 2011, om 17:26 heeft Mark Hatle het volgende geschreven:
> 
>> Revised the fixup_perms function in package.bbclass.  Change to using a
>> class based approach for the individual permissions entries.
>>
>> Add support for directory linkages.
>>
>> Add entries to match base-files recipe in the fs-perms.txt.
>>
>> (umask commit is unchanged, resending due to time since last sent)
>>
>> ----
>>
>> V1 log below
>>
>> Add a new 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 user can specify their own settings via the configuration files
>> specified in FILESYSTEM_PERMS_TABLES.  If this is not defined, it will
>> fall back to loading files/fs-perms.txt from BBPATH.  The format of this
>> file is documented within the file.
>>
>> By default all of the system directories, specified in bitbake.conf, will
>> be fixed to be 0755, root, root.
>>
>> The fs-perms.txt contains a few default entries to correct documentation,
>> locale, headers and debug sources.  It was discovered these are often
>> incorrect due to being directly copied from the build user environment.
>>
>> Also tweak a couple of warnings to provide more diagnostic information.
> 
> Does this rely on the umask feature in bitbake master? If so, we should check the minumum bitbake requirements again

It relies upon it, however no failures will occur if bitbake master doesn't
support the umask control.  (Of course then the user's umask is inherited.)

--Mark

> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core