Re: We currently have a problem with cp -a /media/cdrom /etc

[James Antill <james.antill@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2643 bytes --]

kOn Fri, 2007-01-12 at 13:55 -0500, Stephen Smalley wrote:
> On Fri, 2007-01-12 at 13:46 -0500, Daniel J Walsh wrote:
> > Currently in policy we do NOT have the following rule
> > 
> > allow iso9660_t fs_t:filesystem associate;
> > 
[...]
> > Maybe a fix would be to allow cp to ask the kernel what to do if it can 
> > not setfscreatecon a particular context on a file system.

 Note that copy.c uses fsetfilecon() on the open fd of the new file, but
it saves the context of the old file in setfscreatecon() (and so does
open+getfscreatecon+fsetfilecon). Fixing this to just store in a local
variable would mean we'd see the error at setfilecon() time.

> > Thoughts?
> 
> First, I seem to recall debates about whether -p (and thus -a) should
> automatically enable preservation of SELinux context or whether that
> should remain a separate option only.  Pros and cons to both sides.

 I never saw the original discussion, but I'm 99% sure I complained to
Jim and/or Dan that cp -a/-p should do "the right thing" and preserve
everything, when I was adding the xattr support.
 Note that the changes in question are not really consistent:


               FC-5           FC-6            rawhide          

mode = acls[1] yes            yes             no
-p             trad.          trad.           trad.+acls+xattrs
-a             -dpPR          -dpPRc          -dpPR
--preserve=all trad.+context  trad.+context   trad.+context+acls+xattrs

...and in FC-6 -Z also does the open+getfscreatecon+fsetfilecon dance.


> I agree that allowing the association isn't the right thing to do.  Part
> of the problem here is that setfscreatecon() doesn't know where you are
> going to put the file, so it cannot report an error at that time, and
> the open/mkdir failure could happen for a variety of reasons, not just
> this one.

 So if we moved coreutils to just using fsetfilecon() for -p/-a, could
we do something?

> cp could fall back to resetting fscreate to NULL and try again in that
> case (as long as the user didn't explicitly request preservation via
> --preserve=context).

 I'm not sure that's the right behaviour, I think the behaviour should
be like if you copy an ACL to an FS that doesn't support them (Ie. it
knows what failed, and why ... and so "does the right thing").


[1] This means that preserving the "unix permission mode bits" implies
preserving any ACLs.

-- 
James Antill - <james.antill@redhat.com>
setsockopt(fd, IPPROTO_TCP, TCP_CONGESTION, ...);
setsockopt(fd, IPPROTO_TCP, TCP_DEFER_ACCEPT, ...);
setsockopt(fd, SOL_SOCKET,  SO_ATTACH_FILTER, ...);


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]