|
From: | Pádraig Brady |
Subject: | Re: Make coretutils work better with SELinux. |
Date: | Thu, 01 Nov 2012 19:47:24 +0000 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 |
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 ~/mywebThanks 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.
[Prev in Thread] | Current Thread | [Next in Thread] |