does mv need a --context=CTX (-Z) option, too?

does mv need a --context=CTX (-Z) option, too?

[Jim Meyering]

It might make sense to add a --context=CTX (-Z) option to mv.  Currently,
cp, install, mkdir, mknod, mkfifo all have that option, but not mv.
Most of the time, mv would have no need, since it simply calls rename.
But when that fails, it reverts to using the very same copying code
(copy.c) that cp uses.  It is trivial to add this option to mv, with the
understanding that it'd take effect solely for e.g., cross-device moves.
I.e., if you want to simulate a cross device move, you'd have to use
cp -pr and rm -rf, so if it makes sense for cp to have the --context=CTX
(-Z) option, then it follows that mv must accept it as well.

This brings up another minor inconsistency: should the other
named-file-creation programs (dd, ln, link, touch) in coreutils also
accept the --context=CTX (-Z) option?

With that only partly rhetorical question, you should see why I'd like
an selinux/kernel hook that'd let me set the default fscreate context
for the upcoming execve.  Then I could simply add one option to runcon
and forget about all of these "-Z CTX" options.  IMHO, requiring all of
these tools to add an option like "-Z CTX" to perform the same simple
function is almost prohibitively onerous.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: does mv need a --context=CTX (-Z) option, too?

[kmacmillan]

On Thu, 10 Aug 2006, Jim Meyering wrote:

> It might make sense to add a --context=CTX (-Z) option to mv.  Currently,
> cp, install, mkdir, mknod, mkfifo all have that option, but not mv.
> Most of the time, mv would have no need, since it simply calls rename.
> But when that fails, it reverts to using the very same copying code
> (copy.c) that cp uses.  It is trivial to add this option to mv, with the
> understanding that it'd take effect solely for e.g., cross-device moves.
> I.e., if you want to simulate a cross device move, you'd have to use
> cp -pr and rm -rf, so if it makes sense for cp to have the --context=CTX
> (-Z) option, then it follows that mv must accept it as well.
>

I think that mv should have that option. Actually, I think that the more 
pressing option is --preserve so that users can simulate the rename case 
across devices.

> This brings up another minor inconsistency: should the other
> named-file-creation programs (dd, ln, link, touch) in coreutils also
> accept the --context=CTX (-Z) option?
>
> With that only partly rhetorical question, you should see why I'd like
> an selinux/kernel hook that'd let me set the default fscreate context
> for the upcoming execve.  Then I could simply add one option to runcon
> and forget about all of these "-Z CTX" options.  IMHO, requiring all of
> these tools to add an option like "-Z CTX" to perform the same simple
> function is almost prohibitively onerous.
>

As Steve explained, this option is not safe. Trivial example: with this 
mechanism I could potentially cause passwd to create /etc/shadow with any 
context (well, passwd explicitly requests that context so that wouldn't 
work, but I think you get the idea). SELinux goes to great lengths to 
make execve safe for gaining privileges - this would go against that 
goal.

Karl

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: does mv need a --context=CTX (-Z) option, too?

[Jim Meyering]

kmacmillan@mentalrootkit.com wrote:
> On Thu, 10 Aug 2006, Jim Meyering wrote:
>
>> It might make sense to add a --context=CTX (-Z) option to mv.  Currently,
>> cp, install, mkdir, mknod, mkfifo all have that option, but not mv.
>> Most of the time, mv would have no need, since it simply calls rename.
>> But when that fails, it reverts to using the very same copying code
>> (copy.c) that cp uses.  It is trivial to add this option to mv, with the
>> understanding that it'd take effect solely for e.g., cross-device moves.
>> I.e., if you want to simulate a cross device move, you'd have to use
>> cp -pr and rm -rf, so if it makes sense for cp to have the --context=CTX
>> (-Z) option, then it follows that mv must accept it as well.
>>
>
> I think that mv should have that option. Actually, I think that the more
> pressing option is --preserve so that users can simulate the rename case
> across devices.

Why would mv need a new --preserve option?
mv already tries to preserve as much as possible when
performing any cross-device copy.

Admittedly, mv doesn't fail if it cannot preserve some attribute,
but that's a POSIX requirement (cp -p *does*).  Maybe you'd like
--preserve to change that?  I added a comment suggesting
just such a change years ago.  From coreutils/src/mv.c:
  x->require_preserve = false;  /* FIXME: maybe make this an option */
but no one has been motivated to do that.
SELinux might be the necessary prod.

A related option I've contemplated adding to mv is one that'd make it
perform the move operation only if rename succeeds.  I.e., don't fall
back on copy/remove.

>> This brings up another minor inconsistency: should the other
>> named-file-creation programs (dd, ln, link, touch) in coreutils also
>> accept the --context=CTX (-Z) option?
>>
>> With that only partly rhetorical question, you should see why I'd like
>> an selinux/kernel hook that'd let me set the default fscreate context
>> for the upcoming execve.  Then I could simply add one option to runcon
>> and forget about all of these "-Z CTX" options.  IMHO, requiring all of
>> these tools to add an option like "-Z CTX" to perform the same simple
>> function is almost prohibitively onerous.
>>
>
> As Steve explained, this option is not safe. Trivial example: with this
> mechanism I could potentially cause passwd to create /etc/shadow with any
> context (well, passwd explicitly requests that context so that wouldn't
> work, but I think you get the idea). SELinux goes to great lengths to
> make execve safe for gaining privileges - this would go against that
> goal.

I realize that many programs do depend on the current semantics
(where, upon exec, the fscreate is guaranteed to be the default),
so obviously any change that simply removes that guarantee would
break things.  A change like I'm hinting at would require more
than that.  Perhaps a policy as simple as allowing a new, non-default
fscreate context IFF some other measure (exec context?) remains the
same.  So, for a program like passwd that gets elevated privilege,
setting the apply-on-exec fscreate context would have no effect.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: does mv need a --context=CTX (-Z) option, too?

[James Antill]

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

On Thu, 2006-08-10 at 17:15 +0200, Jim Meyering wrote:
> kmacmillan@mentalrootkit.com wrote:
> > On Thu, 10 Aug 2006, Jim Meyering wrote:
> >
> >> It might make sense to add a --context=CTX (-Z) option to mv.  Currently,
> >> cp, install, mkdir, mknod, mkfifo all have that option, but not mv.
> >> Most of the time, mv would have no need, since it simply calls rename.
> >> But when that fails, it reverts to using the very same copying code
> >> (copy.c) that cp uses.  It is trivial to add this option to mv, with the
> >> understanding that it'd take effect solely for e.g., cross-device moves.
> >> I.e., if you want to simulate a cross device move, you'd have to use
> >> cp -pr and rm -rf, so if it makes sense for cp to have the --context=CTX
> >> (-Z) option, then it follows that mv must accept it as well.
> >>
> >
> > I think that mv should have that option. Actually, I think that the more
> > pressing option is --preserve so that users can simulate the rename case
> > across devices.
> 
> Why would mv need a new --preserve option?
> mv already tries to preserve as much as possible when
> performing any cross-device copy.

 Then, IMO, it should preserve xattrs and SELinux context by default
too. It already seems to try and do ACLs (although it's a bit
weird[1]) ... so this seems natural. I really wouldn't want to explain
what a mv -Z call did to someone.

> Admittedly, mv doesn't fail if it cannot preserve some attribute,
> but that's a POSIX requirement (cp -p *does*).  Maybe you'd like
> --preserve to change that?  I added a comment suggesting
> just such a change years ago.  From coreutils/src/mv.c:
>   x->require_preserve = false;  /* FIXME: maybe make this an option */
> but no one has been motivated to do that.
> SELinux might be the necessary prod.

 That might be useful, esp. with ACLs and SELinux context.


[1] strace shows:

getxattr("/boot/james/abcd", "system.posix_acl_access", 0xbfdbd580, 132) = -1 EOPNOTSUPP (Operation not supported)
setxattr("./abcd", "system.posix_acl_access", "\x02\x00\x00\x00\x01\x00\x06\x00\xff\xff\xff\xff\x04\x00\x04\x00\xff\xff\xff\xff \x00\x04\x00\xff\xff\xff\xff", 28, 0) = 0

...which is pretty surprising.

-- 
James Antill <jantill@redhat.com>

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

Re: does mv need a --context=CTX (-Z) option, too?

[Karl MacMillan]

On Thu, 2006-08-10 at 17:15 +0200, Jim Meyering wrote:
> kmacmillan@mentalrootkit.com wrote:
> > On Thu, 10 Aug 2006, Jim Meyering wrote:
> >
> >> It might make sense to add a --context=CTX (-Z) option to mv.  Currently,
> >> cp, install, mkdir, mknod, mkfifo all have that option, but not mv.
> >> Most of the time, mv would have no need, since it simply calls rename.
> >> But when that fails, it reverts to using the very same copying code
> >> (copy.c) that cp uses.  It is trivial to add this option to mv, with the
> >> understanding that it'd take effect solely for e.g., cross-device moves.
> >> I.e., if you want to simulate a cross device move, you'd have to use
> >> cp -pr and rm -rf, so if it makes sense for cp to have the --context=CTX
> >> (-Z) option, then it follows that mv must accept it as well.
> >>
> >
> > I think that mv should have that option. Actually, I think that the more
> > pressing option is --preserve so that users can simulate the rename case
> > across devices.
> 
> Why would mv need a new --preserve option?
> mv already tries to preserve as much as possible when
> performing any cross-device copy.
> 

I had the impression that mv did not preserve contexts across devices,
but I guess I was mistaken.

> Admittedly, mv doesn't fail if it cannot preserve some attribute,
> but that's a POSIX requirement (cp -p *does*).  Maybe you'd like
> --preserve to change that?  I added a comment suggesting
> just such a change years ago.  From coreutils/src/mv.c:
>   x->require_preserve = false;  /* FIXME: maybe make this an option */
> but no one has been motivated to do that.
> SELinux might be the necessary prod.

That might be nice, but I don't know that it is required.

> A related option I've contemplated adding to mv is one that'd make it
> perform the move operation only if rename succeeds.  I.e., don't fall
> back on copy/remove.
> 

<snip>

> >
> > As Steve explained, this option is not safe. Trivial example: with this
> > mechanism I could potentially cause passwd to create /etc/shadow with any
> > context (well, passwd explicitly requests that context so that wouldn't
> > work, but I think you get the idea). SELinux goes to great lengths to
> > make execve safe for gaining privileges - this would go against that
> > goal.
> 
> I realize that many programs do depend on the current semantics
> (where, upon exec, the fscreate is guaranteed to be the default),
> so obviously any change that simply removes that guarantee would
> break things.  A change like I'm hinting at would require more
> than that.  Perhaps a policy as simple as allowing a new, non-default
> fscreate context IFF some other measure (exec context?) remains the
> same.  So, for a program like passwd that gets elevated privilege,
> setting the apply-on-exec fscreate context would have no effect.

Yeah - if there is no change in context that would be safe. Other
comments in the thread seem to be suggesting that the behavior that is
really needed for most of coreutils is just the preservation contexts,
so the need for this change doesn't seem as pressing (touch being the
exception - it probably needs --context).

Karl

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: does mv need a --context=CTX (-Z) option, too?

[Jim Meyering]

Karl MacMillan <kmacmillan@mentalrootkit.com> wrote:

> On Thu, 2006-08-10 at 17:15 +0200, Jim Meyering wrote:
>> kmacmillan@mentalrootkit.com wrote:
>> > On Thu, 10 Aug 2006, Jim Meyering wrote:
>> >
>> >> It might make sense to add a --context=CTX (-Z) option to mv.  Currently,
>> >> cp, install, mkdir, mknod, mkfifo all have that option, but not mv.
>> >> Most of the time, mv would have no need, since it simply calls rename.
>> >> But when that fails, it reverts to using the very same copying code
>> >> (copy.c) that cp uses.  It is trivial to add this option to mv, with the
>> >> understanding that it'd take effect solely for e.g., cross-device moves.
>> >> I.e., if you want to simulate a cross device move, you'd have to use
>> >> cp -pr and rm -rf, so if it makes sense for cp to have the --context=CTX
>> >> (-Z) option, then it follows that mv must accept it as well.
>> >>
>> >
>> > I think that mv should have that option. Actually, I think that the more
>> > pressing option is --preserve so that users can simulate the rename case
>> > across devices.
>>
>> Why would mv need a new --preserve option?
>> mv already tries to preserve as much as possible when
>> performing any cross-device copy.
>
> I had the impression that mv did not preserve contexts across devices,
> but I guess I was mistaken.

Red Hat's version may not, I don't remember off hand.
The version I'm working on for upstream most definitely does.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: does mv need a --context=CTX (-Z) option, too?

[Stephen Smalley]

On Thu, 2006-08-10 at 12:13 +0200, Jim Meyering wrote:
> It might make sense to add a --context=CTX (-Z) option to mv.  Currently,
> cp, install, mkdir, mknod, mkfifo all have that option, but not mv.
> Most of the time, mv would have no need, since it simply calls rename.
> But when that fails, it reverts to using the very same copying code
> (copy.c) that cp uses.  It is trivial to add this option to mv, with the
> understanding that it'd take effect solely for e.g., cross-device moves.
> I.e., if you want to simulate a cross device move, you'd have to use
> cp -pr and rm -rf, so if it makes sense for cp to have the --context=CTX
> (-Z) option, then it follows that mv must accept it as well.

mv should just preserve the context of the original in all cases,
whether it is just doing a rename(2) or copying the file.  

> This brings up another minor inconsistency: should the other
> named-file-creation programs (dd, ln, link, touch) in coreutils also
> accept the --context=CTX (-Z) option?

ln/link likewise wouldn't need it, as it is the inodes that are labeled,
not the links.  Unless you mean for ln -s, where the symlink itself has
a label.

> With that only partly rhetorical question, you should see why I'd like
> an selinux/kernel hook that'd let me set the default fscreate context
> for the upcoming execve.  Then I could simply add one option to runcon
> and forget about all of these "-Z CTX" options.  IMHO, requiring all of
> these tools to add an option like "-Z CTX" to perform the same simple
> function is almost prohibitively onerous.

It's consistent with the idea of MAC being a first class citizen of
Linux, just like file owner/mode/ACL.

Now, as far as preserving fscreate across execve goes, doing that in the
case where there is no change in the current context of the task is
conceivable (so no implications for letting the caller influence the
program), although it would be a change in behavior that has been
present for quite some time (and seems rather late to make it into e.g.
RHEL5 or FC6).  I have no strong opinion on that, but it could introduce
unexpected behaviors; some programs today might be setting fscreate and
exec'ing helpers while not expecting the helpers to pick up that
fscreate context.
  
-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: does mv need a --context=CTX (-Z) option, too?

[Jim Meyering]

Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On Thu, 2006-08-10 at 12:13 +0200, Jim Meyering wrote:
>> It might make sense to add a --context=CTX (-Z) option to mv.  Currently,
>> cp, install, mkdir, mknod, mkfifo all have that option, but not mv.
>> Most of the time, mv would have no need, since it simply calls rename.
>> But when that fails, it reverts to using the very same copying code
>> (copy.c) that cp uses.  It is trivial to add this option to mv, with the
>> understanding that it'd take effect solely for e.g., cross-device moves.
>> I.e., if you want to simulate a cross device move, you'd have to use
>> cp -pr and rm -rf, so if it makes sense for cp to have the --context=CTX
>> (-Z) option, then it follows that mv must accept it as well.
>
> mv should just preserve the context of the original in all cases,
> whether it is just doing a rename(2) or copying the file.

What if it's not possible to preserve the original, yet it
would be possible to set some other desirable context?

Stepping back a little, if mv doesn't need the option, then why
does cp need it?  After all, cp has no option to set classic
permissions.

>> This brings up another minor inconsistency: should the other
>> named-file-creation programs (dd, ln, link, touch) in coreutils also
>> accept the --context=CTX (-Z) option?
>
> ln/link likewise wouldn't need it, as it is the inodes that are labeled,
> not the links.  Unless you mean for ln -s, where the symlink itself has
> a label.

You're right that link isn't an issue.
However, for consistency, ln (for -s), dd, and touch seem like
they would need the new option, No?

>> With that only partly rhetorical question, you should see why I'd like
>> an selinux/kernel hook that'd let me set the default fscreate context
>> for the upcoming execve.  Then I could simply add one option to runcon
>> and forget about all of these "-Z CTX" options.  IMHO, requiring all of
>> these tools to add an option like "-Z CTX" to perform the same simple
>> function is almost prohibitively onerous.
>
> It's consistent with the idea of MAC being a first class citizen of
> Linux, just like file owner/mode/ACL.

Slightly off-topic...
What if ACLs come into vogue?
Should I expect (longer term) to have an option to set
an ACL as well, in each of these programs?

> Now, as far as preserving fscreate across execve goes, doing that in the
> case where there is no change in the current context of the task is
> conceivable (so no implications for letting the caller influence the
> program), although it would be a change in behavior that has been
> present for quite some time (and seems rather late to make it into e.g.
> RHEL5 or FC6).

I don't expect any of these upstream coreutils changes to affect RHEL5
or FC6 either, so that's fine.  The important thing, from my standpoint,
is to avoid adding these -Z options if they're not absolutely necessary.

> I have no strong opinion on that, but it could introduce
> unexpected behaviors; some programs today might be setting fscreate and
> exec'ing helpers while not expecting the helpers to pick up that
> fscreate context.

But if there is some *new* interface (and underlying data structure
support) that sets the to-be-used-upon-exec fscreate context, then
no preexisting program would be affected, since they wouldn't be
using the new interface.

I'd like to be able to write a new program (let's call it fscon) that'd
take an fscreate context, FSC and exec a user-specified program for
which FSC would be the default.

That would obviate most of these -Z options, and more importantly, would
help more applications work with SELinux without requiring source changes.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: does mv need a --context=CTX (-Z) option, too?

[Daniel J Walsh]

Jim Meyering wrote:
> Stephen Smalley <sds@tycho.nsa.gov> wrote:
>   
>> On Thu, 2006-08-10 at 12:13 +0200, Jim Meyering wrote:
>>     
>>> It might make sense to add a --context=CTX (-Z) option to mv.  Currently,
>>> cp, install, mkdir, mknod, mkfifo all have that option, but not mv.
>>> Most of the time, mv would have no need, since it simply calls rename.
>>> But when that fails, it reverts to using the very same copying code
>>> (copy.c) that cp uses.  It is trivial to add this option to mv, with the
>>> understanding that it'd take effect solely for e.g., cross-device moves.
>>> I.e., if you want to simulate a cross device move, you'd have to use
>>> cp -pr and rm -rf, so if it makes sense for cp to have the --context=CTX
>>> (-Z) option, then it follows that mv must accept it as well.
>>>       
>> mv should just preserve the context of the original in all cases,
>> whether it is just doing a rename(2) or copying the file.
>>     
>
> What if it's not possible to preserve the original, yet it
> would be possible to set some other desirable context?
>
> Stepping back a little, if mv doesn't need the option, then why
> does cp need it?  After all, cp has no option to set classic
> permissions.
>
>   
I agree cp should not need this qualifier.  It should either be preserve 
or get the new default context.
mv should just try to preserve
install should use the matchpathcon similar to rpm.
>>> This brings up another minor inconsistency: should the other
>>> named-file-creation programs (dd, ln, link, touch) in coreutils also
>>> accept the --context=CTX (-Z) option?
>>>       
>> ln/link likewise wouldn't need it, as it is the inodes that are labeled,
>> not the links.  Unless you mean for ln -s, where the symlink itself has
>> a label.
>>     
>
> You're right that link isn't an issue.
> However, for consistency, ln (for -s), dd, and touch seem like
> they would need the new option, No?
>
>   
>>> With that only partly rhetorical question, you should see why I'd like
>>> an selinux/kernel hook that'd let me set the default fscreate context
>>> for the upcoming execve.  Then I could simply add one option to runcon
>>> and forget about all of these "-Z CTX" options.  IMHO, requiring all of
>>> these tools to add an option like "-Z CTX" to perform the same simple
>>> function is almost prohibitively onerous.
>>>       
>> It's consistent with the idea of MAC being a first class citizen of
>> Linux, just like file owner/mode/ACL.
>>     
>
> Slightly off-topic...
> What if ACLs come into vogue?
> Should I expect (longer term) to have an option to set
> an ACL as well, in each of these programs?
>
>   
No I think we should follow the DAC rules.
>> Now, as far as preserving fscreate across execve goes, doing that in the
>> case where there is no change in the current context of the task is
>> conceivable (so no implications for letting the caller influence the
>> program), although it would be a change in behavior that has been
>> present for quite some time (and seems rather late to make it into e.g.
>> RHEL5 or FC6).
>>     
>
> I don't expect any of these upstream coreutils changes to affect RHEL5
> or FC6 either, so that's fine.  The important thing, from my standpoint,
> is to avoid adding these -Z options if they're not absolutely necessary.
>
>   
>> I have no strong opinion on that, but it could introduce
>> unexpected behaviors; some programs today might be setting fscreate and
>> exec'ing helpers while not expecting the helpers to pick up that
>> fscreate context.
>>     
>
> But if there is some *new* interface (and underlying data structure
> support) that sets the to-be-used-upon-exec fscreate context, then
> no preexisting program would be affected, since they wouldn't be
> using the new interface.
>
> I'd like to be able to write a new program (let's call it fscon) that'd
> take an fscreate context, FSC and exec a user-specified program for
> which FSC would be the default.
>
> That would obviate most of these -Z options, and more importantly, would
> help more applications work with SELinux without requiring source changes.
>
> --
> This message was distributed to subscribers of the selinux mailing list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.
>   

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: does mv need a --context=CTX (-Z) option, too?

[Casey Schaufler]

--- Daniel J Walsh <dwalsh@redhat.com> wrote:


> I agree cp should not need this qualifier.  It
> should either be preserve 
> or get the new default context.

Classic Unix philosophy is that mv maintains
attributes (moves an object) while cp does
not (creates a new object) except as explicitly
requested. Hence, it's OK for cp to have this
option but not mv. If anything, mv might have
an option that only allows the move if all
attributes can be maintained.



Casey Schaufler
casey@schaufler-ca.com

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: does mv need a --context=CTX (-Z) option, too?

[Daniel J Walsh]

Casey Schaufler wrote:
> --- Daniel J Walsh <dwalsh@redhat.com> wrote:
>
>
>   
>> I agree cp should not need this qualifier.  It
>> should either be preserve 
>> or get the new default context.
>>     
>
> Classic Unix philosophy is that mv maintains
> attributes (moves an object) while cp does
> not (creates a new object) except as explicitly
> requested. Hence, it's OK for cp to have this
> option but not mv. If anything, mv might have
> an option that only allows the move if all
> attributes can be maintained.
>   
I am saying cp should not have a qualified where you specify the 
context.  It should either default to the ordinary system behaviour or 
if preserve is set try to maintain the file context.

Since cp does not have a -mode= or -owner= it probably should not have a 
-context=
>
>
> Casey Schaufler
> casey@schaufler-ca.com
>   


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: does mv need a --context=CTX (-Z) option, too?

[Casey Schaufler]

--- Daniel J Walsh <dwalsh@redhat.com> wrote:


> I am saying cp should not have a qualified where you
> specify the 
> context.  It should either default to the ordinary
> system behaviour or 
> if preserve is set try to maintain the file context.

Sound reasoning.

> Since cp does not have a -mode= or -owner= it
> probably should not have a 
> -context=

Those who advocate commands with lots of
options would say there should be -mode=
and -owner= as well. There is some logic
based on the value of atomic operations to
support that stand, and context is something
that really ought to be set correctly at all
times. I'm good with classic behavior.


Casey Schaufler
casey@schaufler-ca.com

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: does mv need a --context=CTX (-Z) option, too?

[Karl MacMillan]

On Thu, 2006-08-10 at 10:41 -0400, Daniel J Walsh wrote:
> Jim Meyering wrote:
> > Stephen Smalley <sds@tycho.nsa.gov> wrote:
> >   

<snip>

> > Stepping back a little, if mv doesn't need the option, then why
> > does cp need it?  After all, cp has no option to set classic
> > permissions.
> >
> >   
> I agree cp should not need this qualifier.  It should either be preserve 
> or get the new default context.
> mv should just try to preserve

Agreed.

> install should use the matchpathcon similar to rpm.

Though this should be optional because it is fairly expensive. Also,
there is at least some existing software that uses install --context, so
I would hate to see that go.

Karl

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: does mv need a --context=CTX (-Z) option, too?

[Jim Meyering]

Daniel J Walsh <dwalsh@redhat.com> wrote:
> Jim Meyering wrote:
>> Stephen Smalley <sds@tycho.nsa.gov> wrote:
>>
>>> On Thu, 2006-08-10 at 12:13 +0200, Jim Meyering wrote:
>>>
>>>> It might make sense to add a --context=CTX (-Z) option to mv.  Currently,
>>>> cp, install, mkdir, mknod, mkfifo all have that option, but not mv.
>>>> Most of the time, mv would have no need, since it simply calls rename.
>>>> But when that fails, it reverts to using the very same copying code
>>>> (copy.c) that cp uses.  It is trivial to add this option to mv, with the
>>>> understanding that it'd take effect solely for e.g., cross-device moves.
>>>> I.e., if you want to simulate a cross device move, you'd have to use
>>>> cp -pr and rm -rf, so if it makes sense for cp to have the --context=CTX
>>>> (-Z) option, then it follows that mv must accept it as well.
>>>>
>>> mv should just preserve the context of the original in all cases,
>>> whether it is just doing a rename(2) or copying the file.
>>>
>>
>> What if it's not possible to preserve the original, yet it
>> would be possible to set some other desirable context?
>>
>> Stepping back a little, if mv doesn't need the option, then why
>> does cp need it?  After all, cp has no option to set classic
>> permissions.
>>
>>
> I agree cp should not need this qualifier.  It should either be preserve
> or get the new default context.
> mv should just try to preserve
> install should use the matchpathcon similar to rpm.

Thanks, for your replies Dan and Karl.
I'm glad I asked.  Barring objections (Russell?), cp's -Z/--context=CTX
option will not make it to "upstream".

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: does mv need a --context=CTX (-Z) option, too?

[Russell Coker]

On Friday 11 August 2006 03:35, Jim Meyering <meyering@redhat.com> wrote:
> Thanks, for your replies Dan and Karl.
> I'm glad I asked.  Barring objections (Russell?), cp's -Z/--context=CTX
> option will not make it to "upstream".

I think it's OK to have cp and friends just preserve the current context.  
Using matchpathcon is an optional extra, and --context=CTX isn't really 
required.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: does mv need a --context=CTX (-Z) option, too?

[James Antill]

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

On Thu, 2006-08-10 at 09:54 -0400, Stephen Smalley wrote:

> Now, as far as preserving fscreate across execve goes, doing that in the
> case where there is no change in the current context of the task is
> conceivable (so no implications for letting the caller influence the
> program), although it would be a change in behavior that has been
> present for quite some time (and seems rather late to make it into e.g.
> RHEL5 or FC6).  I have no strong opinion on that, but it could introduce
> unexpected behaviors; some programs today might be setting fscreate and
> exec'ing helpers while not expecting the helpers to pick up that
> fscreate context.

 What about dynamic domain transitions? Eg.

task_A = *:foo_t
task_A calls setfscreatecon(*:bad_t)
fork() = task_B
  task_B = *:foo_t
  task_B calls setcon(*:bar_t)
  task_B creates file

-- 
James Antill <jantill@redhat.com>

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