Bug 9430 - fixup_perms fails when both /var/run and /var/lock present
Summary: fixup_perms fails when both /var/run and /var/lock present
Status: RESOLVED FIXED
Alias: None
Product: OE-Core
Classification: Build System, Metadata & Runtime
Component: configuration (show other bugs)
Version: unspecified
Hardware: x86 Multiple
: Medium+ normal
Target Milestone: 2.1 M4
Assignee: Bill Randle
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2016-04-11 02:52 UTC by Denys Dmytriyenko
Modified: 2016-04-21 15:28 UTC (History)
3 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: No (bug/feature does not impact docs)


Attachments
Proposed patch (2.71 KB, patch)
2016-04-12 00:22 UTC, Bill Randle
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Denys Dmytriyenko 2016-04-11 02:52:51 UTC
The file meta/files/fs-perms.txt contains this:

# Items from base-files
# Links
${localstatedir}/run    link    /run
${localstatedir}/log    link    volatile/log
${localstatedir}/lock   link    /run/lock
${localstatedir}/tmp    link    volatile/tmp

Now, when a recipe installs both /var/run and /var/lock, the fixup_perms function of do_package does create /run/lock and symlinks /var/lock into it, but then fails to symlink the actual /var/run into /run with the following error:

ERROR: recipename do_package: QA Issue: Fixup Perms: Unable to correct directory link, target already exists: /var/run -> /run [perm-link]
Comment 1 Bill Randle 2016-04-12 00:22:50 UTC
Created attachment 3118 [details]
Proposed patch

When processing links, the directories are processed in unsorted order which can result in cases like /var/lock -> /run/lock handled before /var/run -> /run throwing an error for /var/run because /run already exists. Change the link processing to ensure links are processed in sorted order of the destination.
Comment 2 Denys Dmytriyenko 2016-04-12 16:51:09 UTC
Seems to resolve the issue for me.
Comment 3 Dan Mcgregor 2016-04-13 18:54:04 UTC
The version in master introduces a new problem. The old code would process the permissions table in order, and later entries would override the first entries. This made overriding parts of the permissions file possible.

As an example, putting:

FILESYSTEM_PERMS_TABLES = "files/fs-perms.txt files/fs-perms-override.txt"

into conf/local.conf, where files/fs-perms.txt is the default from openembedded-core and files/fs-perms-override.txt contains:

# Override OE-core:
${localstatedir}/log    0755    root    root    false   -       -       -
${localstatedir}/tmp    01777   root    root    false   -       -       -
${sysconfdir}/mtab      link    /proc/self/mounts
${ROOT_HOME}            0700    root    root    false   -       -       -

would allow ${localstatedir}/log and ${localstatedir}/tmp to be a real directories.

To demonstrate this, an append on base-files will suffice, so base-files_%.bbappend containing:

volatiles_remove = "log tmp"
dirs755 += "${localstatedir}/log"
dirs1777 += "${localstatedir}/tmp"

produces:

ERROR: base-files-3.0.14-r89 do_package: QA Issue: Fixup Perms: Unable to correct directory link, target already exists: /var/log -> /var/volatile/log [perm-link]
ERROR: base-files-3.0.14-r89 do_package: QA Issue: Fixup Perms: Unable to correct directory link, target already exists: /var/tmp -> /var/volatile/tmp [perm-link]

The same configuration, prior to the version currently in master created /var/log and /var/tmp as real directories.