coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Make coretutils work better with SELinux.


From: Pádraig Brady
Subject: Re: Make coretutils work better with SELinux.
Date: Thu, 01 Nov 2012 00:54:04 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]