On 07/11/2013 03:45 PM, Daniel J Walsh wrote:
> On 07/07/2013 09:37 AM, Pádraig Brady wrote:
> @@ -2231,7 +2236,11 @@ copy_internal (char const *src_name, char const
> *dst_name,
> }
> }
> else if (x->set_security_context)
> - restorecon (dst_name, 1, false);
> + {
> + /* FIXME: Why do we need this exactly?
> + Can we optimize out in certain cases? */
> + restorecon (dst_name, 1, false);
> + }
>
> if (S_ISDIR (src_mode))
> {
> @@ -2467,6 +2476,9 @@ copy_internal (char const *src_name, char const
> *dst_name,
> }
> }
>
> + /* FIXME: Why is this needed exactly?
> + Won't it impact a global setfscreatecon()
> + done for cp --context=... for example? */
> if (x->preserve_security_context)
> restore_default_fscreatecon_or_die ();
>
> DAN> I guess we should check to see if the user specified --context or not?
> Or do we have a conflict on this. IE You are not able to do --context and
> preserve on the same command line.
BTW, that code was from the orig Red Hat Selinux patch.
You're right, the combination I was worried about is not allowed,
so this is fine to leave.
>
> diff --git a/src/cp.c b/src/cp.c
> index b84a025..6aaae2c 100644
> --- a/src/cp.c
> +++ b/src/cp.c
> @@ -1188,6 +1188,12 @@ main (int argc, char **argv)
> _("cannot preserve security context "
> "without an SELinux-enabled kernel"));
>
> + /* FIXME: This handles new files. But what about existing files?
> + I.E. if updating a tree, new files would have the specified context,
> + but shouldn't existing files be updated for consistency like this?
> + if (scontext)
> + restorecon (dst_path, 0, true);
> + */
>
> DAN> I agree, I think the user would expect everything to be copied to have
> the "correct" label.
>
> if (scontext && setfscreatecon (optarg) < 0)
> error (EXIT_FAILURE, errno,
> _("failed to set default file creation context to %s"),
>
OK I'll see if I can fix that up too.
thanks,
Pádraig.
