Re: [Libguestfs] [PATCH 2/2] Use setfiles from the appliance for the SELinux relabel (RHBZ#1089100).
[Including libguestfs mailing list this time] On Tue, May 27, 2014 at 06:05:15AM -0700, Colin Walters wrote:
On Tue, May 27, 2014, at 02:04 AM, Richard W.M. Jones wrote:
I'm still anxious for Colin to tell us if this API is suitable for his needs.
I'd like an API that allows me to only relabel *unlabeled* files. The use case here is: I have an existing disk image with an OS, I want to inject e.g. a systemd service into it. If I do this offline from libguestfs, the injected /usr/libexec/mydaemon and /usr/lib/systemd/system/mydaemon.service won't be labeled, but everything else will be.
I'm guessing that OStree does not have /etc/selinux/config,
Right, it's in the "deployment root" of /ostree/deploy/$osname/deploy/$checksum/etc/selinux/config
Got it:
<fs> ll /ostree/deploy/project-atomic-controller/deploy/afc1794b4b42df77edf1988897b167573b99e299fa39a15b07b235a0e7387d02.0/etc/selinux/targeted/contexts/files/file_contexts -rw-r--r--. 1 root root 352240 Apr 14 20:14 /sysroot/ostree/deploy/project-atomic-controller/deploy/afc1794b4b42df77edf1988897b167573b99e299fa39a15b07b235a0e7387d02.0/etc/selinux/targeted/contexts/files/file_contexts
To figure that out you'd want to use the OSTree APIs; and then it introduces further questions around *which* deployments you want to relabel. All? Only one (the default?).
What I do currently in my scripts is only relabel the default, and that would be the best default for an API.
But a totally valid thing to do with OSTree is - say you're running RHEL7, and you want to check whether the latest Fedora kernel fixes an issue you're seeing. You can use ostree to dynamically parallel install Fedora content in a new deployment root, try it with near-total safety[1], and then if it doesn't work, just delete it and free up the space.
So I think an API which looks like this ... required params: None optional params: path => Either a directory to be relabelled recursively, or a single file (defaults to "/"). root => Inspection root of guest. Optional, only makes sense when 'contexts' param is *omitted*. contexts => The `file_contexts' file. Defaults to /etc/selinux/$selinux_type/contexts/files/file_contexts OSTree would probably want to pass: /ostree/deploy/$osname/deploy/$checksum/etc/selinux/targeted/contexts/files/file_contexts Inspection could be updated to parse /etc/selinux/config in order to get the default SELinux policy and pass it back through an API such as `inspect-get-selinux-type'. If 'contexts' is omitted, 'root' must be supplied, and it causes an internal call to guestfs_inspect_get_selinux_type (g, root) in order to get the default policy. What do you think? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW
On Tuesday 27 May 2014 14:25:08 Richard W.M. Jones wrote:
So I think an API which looks like this ...
required params:
None
optional params:
path => Either a directory to be relabelled recursively, or a single file (defaults to "/").
root => Inspection root of guest. Optional, only makes sense when 'contexts' param is *omitted*.
contexts => The `file_contexts' file. Defaults to /etc/selinux/$selinux_type/contexts/files/file_contexts
OSTree would probably want to pass:
/ostree/deploy/$osname/deploy/$checksum/etc/selinux/targeted/contexts /files/file_contexts
Inspection could be updated to parse /etc/selinux/config in order to get the default SELinux policy and pass it back through an API such as `inspect-get-selinux-type'.
If 'contexts' is omitted, 'root' must be supplied, and it causes an internal call to guestfs_inspect_get_selinux_type (g, root) in order to get the default policy.
Note that not specifying a root could lead to issues, as the file contexts are relative to a root. So if I say to relabel the path /guestmountpoint/etc/myconfig according to some /path/of/file_contexts without specifying what is the root, how should setfiles know that path is /etc/myconfig mounted at /guestmountpoint? At this point I'm thinking the best option would be making the root a normal (mandatory) argument, leaving path and contexts as optional (with the former being "/" as default value, and the latter as "find it from the root"). In the situation above, path would become a relative path to the specified root (so if I mount a guest into /guest and I want to relabel it only under /etc, I would pass root=/guest and path=/etc). -- Pino Toscano
On Tue, May 27, 2014 at 04:43:31PM +0200, Pino Toscano wrote:
At this point I'm thinking the best option would be making the root a normal (mandatory) argument, leaving path and contexts as optional (with the former being "/" as default value, and the latter as "find it from the root").
IIUC, that would force people to use inspection in order to relabel filesystems. That would prevent Colin's use-case (because libguestfs cannot currently inspect ostree guests, although that in itself is a bug, certainly once ostree becomes established and widely used). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top
On Tuesday 27 May 2014 18:02:16 Richard W.M. Jones wrote:
On Tue, May 27, 2014 at 04:43:31PM +0200, Pino Toscano wrote:
At this point I'm thinking the best option would be making the root a normal (mandatory) argument, leaving path and contexts as optional (with the former being "/" as default value, and the latter as "find it from the root").
IIUC, that would force people to use inspection in order to relabel filesystems. That would prevent Colin's use-case (because libguestfs cannot currently inspect ostree guests, although that in itself is a bug, certainly once ostree becomes established and widely used).
(Taking this back from the dust...) The problem with making the root optional is that the SELinux tools need to know what is the root of the system where files are being relabeled, since contexts are relative to this root. After all, in Colin's use case OSTree should know where are all the roots already, shouldn't it? -- Pino Toscano
participants (2)
-
Pino Toscano -
Richard W.M. Jones