From: Casey Schaufler <casey@schaufler-ca.com>
To: russell@coker.com.au, casey@schaufler-ca.com
Cc: Stephen Smalley <sds@tycho.nsa.gov>, SE Linux <selinux@tycho.nsa.gov>
Subject: Re: We currently have a problem with cp -a /media/cdrom /etc
Date: Sat, 13 Jan 2007 12:01:48 -0800 (PST) [thread overview]
Message-ID: <534132.51731.qm@web36615.mail.mud.yahoo.com> (raw)
In-Reply-To: <200701132013.04807.russell@coker.com.au>
--- Russell Coker <russell@coker.com.au> wrote:
> Do "most" systems have a copy of MV that preserves
> MAC attributes (and
> therefore is a privileged process)? Or are you just
> referring to the case of
> moving files within a filesystem?
The "desired" behavior (mv retains, cp resets)
is an artifact of the behavior of the underlying
system calls used to implement the commands,
and nothing more. There has always been tension
around the behavior of mv when two file systems
are involved. Doing a link and an unlink has no
effect on the attribues of the file beyond a
brief increase in the link count, so mv "ought"
not need to worry about mode bits, ACLs, MAC
labels, or much of anything. When mv devolves
into a cp and an rm preserving the illusion of
the same file system behavior is hard,
especially when "the community" can't agree on
what attributes matter.
> I can imagine the benefits in having mv and cp
> preserve the context of files,
> and it shouldn't be difficult to implement.
Remember the rule: mv acts as if you did rename.
cp acts as if you created a new thing with the
same contents as the old one.
As for what MLS systems have done, mv needs no
attention on the local file system and relies
on cp behavior off file system. cp makes a copy
with the user's attribute settings. Some have
tried to make mv off local attempt to do its
best to retain attributes, but always leave the
failure to do so a possibility.
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.
next prev parent reply other threads:[~2007-01-13 20:01 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-12 18:46 We currently have a problem with cp -a /media/cdrom /etc Daniel J Walsh
2007-01-12 18:55 ` Stephen Smalley
2007-01-12 20:10 ` James Antill
2007-01-12 20:24 ` Stephen Smalley
2007-01-12 20:29 ` Stephen Smalley
2007-01-12 22:29 ` Casey Schaufler
2007-01-13 9:13 ` Russell Coker
2007-01-13 20:01 ` Casey Schaufler [this message]
2007-01-12 21:15 ` James Antill
2007-01-12 21:19 ` Stephen Smalley
2007-01-13 10:05 ` Jim Meyering
2007-01-15 5:16 ` James Antill
2007-01-15 7:54 ` Jim Meyering
2007-01-16 13:33 ` Stephen Smalley
2007-01-13 10:55 ` Russell Coker
2007-01-12 21:01 ` Stephen Smalley
2007-01-12 21:29 ` Jim Meyering
2007-01-12 21:19 ` Jim Meyering
2007-01-12 21:21 ` Stephen Smalley
2007-01-12 21:47 ` Jim Meyering
2007-01-12 21:56 ` Stephen Smalley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=534132.51731.qm@web36615.mail.mud.yahoo.com \
--to=casey@schaufler-ca.com \
--cc=russell@coker.com.au \
--cc=sds@tycho.nsa.gov \
--cc=selinux@tycho.nsa.gov \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.