Re: Make coretutils work better with SELinux.

[Pádraig Brady]

On 11/01/2012 06:42 PM, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 11/01/2012 11:47 AM, Pádraig Brady wrote:
> > On 11/01/2012 01:20 PM, Daniel J Walsh wrote:
> > > -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> > >
> > > On 10/31/2012 08:54 PM, Pádraig Brady wrote:
> > > > On 10/30/2012 02:43 PM, Daniel J Walsh wrote:
> > > > > -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> > > > >
> > > > > For some reason I could not get git to take more then a one line
> > > > > comment. This is the comment I was trying to add.
> > > > >
> > > > >
> > > > > build: Change -Z opt w/out arg label target with default label
> > > > >
> > > > > The -Z without argument will ask SELinux what the default label of
> > > > > the i dest object should be and then attempt to change it.
> > > > >
> > > > > The -Z with an optional context will create all targets with the
> > > > > optional label. This is still supported for backwards compatability.
> > > > >
> > > > > The mv command does not support the optional argument.
> > > > >
> > > > >
> > > > > BTW, it looks like coreutils has removed -ZCONTEXT from cp, if I had
> > > > > my druthers, I would make all commands just use -Z and not allow the
> > > > > optional arg.  Then -Z would just set the default label.  I would
> > > > > bet that no one in history has executed a command like:
> > > > >
> > > > > mkdir -Zunconfined_u:object_r:httpd_user_content_t:s0 ~/myweb
> > > >
> > > > Thanks for the update.
> > > >
> > > > Short options with optional args are very problematic. It would mean
> > > > `cp -aZ` was OK while `cp -Za` was not etc. Also in Red Hat distros,
> > > > `cp -Z` requires an arg, so changing that would mean that older scripts
> > > > that used `cp -Z blah...` would break with newer cp, as a space is not
> > > > allowed for optional args.
> > > >
> > > > For that reason I would keep -Z and --context as is, but deprecate them
> > > > for the commands that set a context, and add a new --new-context option
> > > > that could take the optional arg:
> > > >
> > > > In that way, -Z can continue to be used as it is commonly with
> > > > commands like `ls` etc. to _read_ the context. Whereas the currently
> > > > rare form of {mkdir,cp,install} -Z context:to_write can be deprecated
> > > > in favor of:
> > > >
> > > > --new-context[=CONTEXT] set security context to CONTEXT, or set context
> > > > to the system default for the destination.
> > > >
> > > > I'm mildly in favor of introducing --new-context, over just making
> > > > --context take an optional arg (so that it's obvious a new context is
> > > > being set, rather than one being copied), but I'm strongly against
> > > > making -Z take an optional arg.
> > > >
> > > > cheers, Pádraig.
> > >
> > > If I made the -Z option not take an optional arg but default to "setting
> > > the default context, on the commands that create new content", are you ok
> > > with that?
> > >
> > > Then make --context or --new-context always take an arg?
> >
> > That would be preferable, but the main worry I'd have with that, is install
> > scripts and packages etc. in Red Hat land doing: `install -Z
> > context:to_write ...`
> >
> > I don't think we could break compatibility with that now?
> >
> > thanks, Pádraig.
>
> I would be shocked if we were.  I have never seen anything like that in 10 
> years.
>
> Most people would have no idea how to do it.

Well I certainly respect your knowledge on all things SELinux.
It would be certainly nice to just support -Z, --context[=CONTEXT]
So searching public code using the old form...
  http://searchco.de/?q=%2Finstall.*-Z%2F&cs=on
Gives only one hit
  http://searchco.de/codesearch/view/8385388

So fair enough, it looks like these options were rarely used.
Supporting -Z, --context[=CONTEXT] will be a lot more useful.

Looking again at the common operation of copying files,
maintaining metadata, but set SELinux labels with restorecon.
We would now have as I previously said:

  cp -a --no-preserve=context --context

but now this is also supported:

  cp -a --no-preserve=context -Z

it would be better to support:

  cp -aZ --no-preserve=context

or even better to have -Z imply --no-preserve=context,
and therefore just support this operation with:

  cp -aZ

While the existing -Z doesn't allow overriding -a,
it doesn't seem very well thought out, as currently
`cp -a -Z blah --no-preserve=context` isn't allowed, while
`cp -a --no-preserve=context -Z blah` is.

As for --new-context vs --context...
since this is quite confusing already,
I'd prefer if we used --new-context instead,
but supported --context in the code with
a deprecation notice to use --new-context.

cheers,
Pádraig.