Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

importer: Error importing RPMs which install to /opt (outside of /usr) #624

Closed
wants to merge 3 commits into from

Conversation

cgwalters
Copy link
Member

See #233 - for RPMs which
place files in e.g. /opt, we have different behavior in the treecompose case
(silently drop it) versus package layering (does the wrong thing).

Since the unpacker right now is only used in the layering case, this just
ensures we'll get a consistent error there.

@jlebon
Copy link
Member

jlebon commented Feb 13, 2017

@rh-atomic-bot r+ 59b1b5e

@rh-atomic-bot
Copy link

⌛ Testing commit 59b1b5e with merge c978d8b...

rh-atomic-bot pushed a commit that referenced this pull request Feb 13, 2017
See #233 - for RPMs which
place files in e.g. `/opt`, we have different behavior in the treecompose case
(silently drop it) versus package layering (does the wrong thing).

Since the unpacker right now is only used in the layering case, this just
ensures we'll get a consistent error there.

Closes: #624
Approved by: jlebon
@rh-atomic-bot
Copy link

💔 Test failed - status-atomicjenkins

@cgwalters
Copy link
Member Author

Confused...tests pass here.

@rh-atomic-bot retry

@rh-atomic-bot
Copy link

⌛ Testing commit 59b1b5e with merge bc10e5f...

rh-atomic-bot pushed a commit that referenced this pull request Feb 13, 2017
See #233 - for RPMs which
place files in e.g. `/opt`, we have different behavior in the treecompose case
(silently drop it) versus package layering (does the wrong thing).

Since the unpacker right now is only used in the layering case, this just
ensures we'll get a consistent error there.

Closes: #624
Approved by: jlebon
@jlebon
Copy link
Member

jlebon commented Feb 13, 2017

I was looking into this failure before backporting #622 it case it was wrong in some subtle way... It turned out to be a rather tricky issue.

When we go the second time around to commit the generated tmpfiles.d file, the compose filter gets called back for e.g. / and /usr. And of course, those do not pass the filter (and we also don't check for callback errors there).

This solved it for me:

diff --git a/src/libpriv/rpmostree-unpacker.c b/src/libpriv/rpmostree-unpacker.c
index 8d91c7c..4c3ff74 100644
--- a/src/libpriv/rpmostree-unpacker.c
+++ b/src/libpriv/rpmostree-unpacker.c
@@ -612,9 +612,12 @@ compose_filter_cb (OstreeRepo         *repo,
           return OSTREE_REPO_COMMIT_FILTER_SKIP;
         }
       /* And ensure the RPM installs into supported paths */
-      else if (!(g_str_has_prefix (path, "/usr/") || g_str_has_prefix (path, "/bin/") ||
-                 g_str_has_prefix (path, "/sbin/") || g_str_has_prefix (path, "/lib/") ||
-                 g_str_has_prefix (path, "/lib64/")))
+      else if (!(g_str_equal (path, "/") ||
+                 g_str_equal (path, "/usr")   || g_str_has_prefix (path, "/usr/")  ||
+                 g_str_equal (path, "/bin")   || g_str_has_prefix (path, "/bin/")  ||
+                 g_str_equal (path, "/sbin")  || g_str_has_prefix (path, "/sbin/") ||
+                 g_str_equal (path, "/lib")   || g_str_has_prefix (path, "/lib/")  ||
+                 g_str_equal (path, "/lib64") || g_str_has_prefix (path, "/lib64/")))
         {
           g_set_error (error, G_IO_ERROR, G_IO_ERROR_FAILED,
                        "Unsupported path: %s; See %s",

(Or maybe a hashtable might be more appropriate at this point).

We could just not use a modifier on the second pass and lose selabeling (which is fine since those dirs will already exist). Though we'll probably want the above anyway when we switch over tree composes to use the unpacker.

@rh-atomic-bot
Copy link

💔 Test failed - status-atomicjenkins

This masked an issue in a change I was working on in the filter.
See coreos#233 - for RPMs which
place files in e.g. `/opt`, we have different behavior in the treecompose case
(silently drop it) versus package layering (does the wrong thing).

Since the unpacker right now is only used in the layering case, this just
ensures we'll get a consistent error there.
@cgwalters
Copy link
Member Author

Oooh, masking the errors was insidious 👺 🔪 🤕. I added a patch to fix that first.

@jlebon
Copy link
Member

jlebon commented Feb 14, 2017

@rh-atomic-bot r+ 5e7cc94

@rh-atomic-bot
Copy link

⌛ Testing commit 5e7cc94 with merge ddbaf19...

rh-atomic-bot pushed a commit that referenced this pull request Feb 14, 2017
See #233 - for RPMs which
place files in e.g. `/opt`, we have different behavior in the treecompose case
(silently drop it) versus package layering (does the wrong thing).

Since the unpacker right now is only used in the layering case, this just
ensures we'll get a consistent error there.

Closes: #624
Approved by: jlebon
@rh-atomic-bot
Copy link

☀️ Test successful - status-atomicjenkins
Approved by: jlebon
Pushing ddbaf19 to master...

@mattdm
Copy link

mattdm commented Jun 20, 2017

FWIW, according to FHS 3.0, directories of the form /opt/provider (where provider is a LANANA registered provider, like fedora or rhat or centos) are fair game for the distro: "Distributions may install and otherwise manage software in /opt under an appropriately registered subdirectory." (ref). It's a little ambiguous whether /opt/google is also distro-clear — google is "appropriately registered", but not registered to the distro provider. We should probably clear that up in the FHS, but I think since Google provides an RPM that uses that path, the intent is clear enough.

@jlebon jlebon mentioned this pull request Aug 24, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants