<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body><div>10 months later, I finally made some progress on this.  See:<br></div>
<div> </div>
<div><a href="https://github.com/hughsie/libhif/pull/39">https://github.com/hughsie/libhif/pull/39</a><br></div>
<div> </div>
<div>Which is used by:<br></div>
<div><a href="https://github.com/projectatomic/rpm-ostree/pull/107">https://github.com/projectatomic/rpm-ostree/pull/107</a><br></div>
<div> </div>
<div>However, to make this more useful, I'd like to move forward on having<br></div>
<div>"known OSTree safe" scriptlets (e.g. ldconfig) in known to RPM.  Any<br></div>
<div>thoughts on that?<br></div>
<div> </div>
<div>By far the simplest approach would be moving as much as possible<br></div>
<div>to %posttrans.  For things like ldconfig, it *almost* works except<br></div>
<div>for the case of %post which executes a binary that uses a new<br></div>
<div>shared library introduced by a previous package in the transaction.<br></div>
<div>We could change librpm to automatically delete /etc/ld.so.cache<br></div>
<div>and force the search-all-the-paths mode of the dynamic linker<br></div>
<div>until the end.  I doubt anyone would notice the difference.<br></div>
<div> </div>
<div>On Wed, Apr 23, 2014, at 08:13 AM, Colin Walters wrote:<br></div>
<blockquote type="cite"><div>Hi,<br></div>
<div> </div>
<div>For the rpm-ostree project, I need the ability to whitelist scriptlets.  There are a few reasons for this, but the most critical is that due to the way OSTree uses hardlinks, and because I can't assume I have copy-on-write links, I need to know that scriptlets will cleanly break hardlinks instead of edit-in-place.<br></div>
<div> </div>
<div>For example, suppose I'm layering a package on top of a base tree that contains a shared library.  We need to update /etc/ld.so.cache.  In the traditional RPM model, that package will contain a scriptlet to run /sbin/ldconfig.<br></div>
<div> </div>
<div>I happen to know that /sbin/ldconfig is safe - it creates /etc/ld.so.cache~ and rename()s into place, so I can just run it.  But if the package happens to do something I haven't whitelisted as safe, I need to error out and refuse to install it.<br></div>
<div> </div>
<div>(Note an important side benefit here of moving away from the "whatever arbitrary code you want that runs as root" aspect of scripts)<br></div>
<div> </div>
<div>Now related to this, I'd like to have rpm-ostree take care of executing any subprocesses (and even Lua code potentially).  The reason for this is because *every* rpm-ostree install will be in a chroot.  In the OSTree model, you running system is immutable - so to "upgrade" a package, we make a hardlink farm of the current tree, and re-unpack the new version of of a package on top, then set it up for the next boot.<br></div>
<div> </div>
<div>If you look at software like mock, it does a complex dance to set up things like /proc in the target root and then run yum --installroot.  But if we were in control over all subprocesses launched, we could use systemd to put each scriptlet inside a container, with its own private /proc and such, inside its own mount namespace.  There are a huge number of advantages to this - systemd is very good at isolation, logging, etc.  For example, we could cut off scriptlets from access to physical devices using <a defang_rel="noreferrer" href="https://fedoraproject.org/wiki/Changes/PrivateDevicesAndPrivateNetwork">https://fedoraproject.org/wiki/Changes/PrivateDevicesAndPrivateNetwork</a><br></div>
<div> </div>
<div>So, a few ways to accomplish this:<br></div>
<div> </div>
<div>1) Add rpmtsSetScriptCallback() - This would allow me to set a callback which would be used instead of the fork()/exec() bits in rpmScriptRun.  I could analyze the script content, and exec it myself using something like "systemd-run".<br></div>
<div> </div>
<div>2) Have rpm-ostree extract the scripts manually *before* the transaction, analyze them, unpack all of the rpms, then run all of the scripts as if they were %posttrans anyways<br></div>
<div> </div>
<div>I need to do a bit more evaluation, but the more I think about it the more I like #2 as it maximizes control.  If we go that route though there's a detail - Lua-based scripts.  In order to implement these it's a bit harder as I'd need to exec a new RPM process inside the root and run the script inside that process.  Maybe I could get away with just ignoring Lua scripts, I suspect many of them are there to work around things like "can't replace directory with symlink" problem that OSTree itself fixes.<br></div>
<div> </div>
<div>Thoughts?<br></div>
<div><u>_______________________________________________</u><br></div>
<div>Rpm-maint mailing list<br></div>
<div><a defang_rel="noreferrer" href="mailto:Rpm-maint@lists.rpm.org">Rpm-maint@lists.rpm.org</a><br></div>
<div><a defang_rel="noreferrer" href="http://lists.rpm.org/mailman/listinfo/rpm-maint">http://lists.rpm.org/mailman/listinfo/rpm-maint</a><br></div>
</blockquote><div> </div>
</body>
</html>