Subject: bug#17103: regression: cp -al doesn't copy symlinks, but tries to link to them (fail)

From: Linda Walsh <[email-masked]>
Date: Wed, 26 Mar 2014 20:40:56 -0700

Pádraig Brady wrote:
> I think I see the reason for excluding symlinks here.
> It's so one is able to remove a sensitive symlink and know there
> are no more links to it that could be later replaced back.
> Allowing that could bypass subsequent "protected_symlinks" checks.
---
What would a 'sensitive symlink' be?

I.e. AFAIK, any user can create a symlink to any file in
a directory they own.  That doesn't give any privilege that
I am aware of -- it's just a "shortcut" to the file.

hardlinks, I could see a that since the user is incrementing
(and changing the link count in the inode), they'll end up
changing the CTIME value -- before, nothing controlled that.

> 
> Now we could fall back to creating separate symlinks,
> like we do on systems that don't support hard links to symlinks.
----
In my case, that's 1) what I thought it was doing, 2) all that is
needed, as I'm using the 2nd area as a build-tree.  I wanted
the source files r/o (i.e. I'd prefer I not have write access so I
don't accidently change the sources in the source tree.

But I didn't even think about this problem when I first encountered
it -- I just made sure setGID was set on the dirs and made sure
they were group writeable.

Of course, IMO, I'm less protected than I was before, as before,
I'd have to explicity su/sudo to root to change a root-owned file.
But now.. I can just write to it because I've ensured group has
write.

> This could be useful given that these less security
> sensitive symlinks might be just as useful to the user.
> I've attached a patch for illustration.
----
The security wasn't an issue until the changes went in ..
couldn't be that long ago.. but don't know.

> 
> However I don't like it because it doesn't deal with,
> 1. fifos, device files, setuid regular files, nor,
> 2. relative symlinks that traverse outside the copied hierarchy.
----
	Well, that's ok ..... I'm not using it to create a mirror.
Just a linked copy that if I want to change a source file, I have
had to move the original out of the way to save any edits.  Which now
I don't... wonderful.	
	But for devices, at least, recreating the same device
by Maj,Min & type would be fine for the purpose you mention.

Not sure how often people use that to mirror.. certainly one wouldn't
normally think to link to a device in /dev:

> ln /dev/zero xxx
ln: failed to create hard link ‘xxx’ => ‘/dev/zero’: Invalid cross-device link

If it is in my own directory, it works, but not sure if I care...
Fifos are a bit different, no?  Aren't they uniq /path?

But still, if I was doing a copy of something that was
uniq, I wouldn't expect to be able to do anything other than
make a symlink to it somewhere.

suidfiles... someone might expect that.. but its never been a feature
I've relied on, since almost any change used to turn off the suid feature
and require explicitly resetting it... but it appears that isn't
true now either.

> 3. Also if you were using `cp -al source mirror`, and subsequently
> wanted to use the link count to see what was added in source,
> then symlinks having a link count of only 1 would mess that up.
----
	Um... if you are trying to use cp -al source mirror and you
can't copy the symlink (or create a symlink to it), the issue is
moot.

I.e. I think the proposal.. and what I thought cp already, effectively
did, was link to what was linkable and copy the rest.

It doesn't' link to directories either -- which some OS's allow,
does that mean take it out for files?  If the OS disallows a 'linkto'
action, then it would be sensible to at least try to make a copy of it

If I really want an exact copy, I'd su to root and probably use
a dump & restore...

> 
> So given this is a system security policy that's restricting the operation,
> and falling back to a less security sensitive operation has at least
> the above 3 disadvantages, I'm not sure there is anything we should do here.
---
	What disadvantages?   If cp already does this on systems
that don't support hardlinking, that's what we have here.  linux
has changed, and no longer allows except under special circumstances.

	Given that, as close a copy ("-a" should be made)...
I.e. I want cp to do, *literally* what the manpage says...

create a copy, but link to files (which posix can redefine to include
directories -- but it would change whether or not linux could link
to them).   I don't consider the devices/fifos etc. to be files.
They are types of FS objects but a file is something that holds data
(by common understanding, not posix "new speak").

goto google and type in "what is a file"...

It's a resource for storing information... a collection of data or
information...etc.  That doesn't really include sockets, fifos, pipes
and devices...

Except for the setuid issue -- but even there -- if the user is in
the affected group, that should be mutated into a copy as well.

Since you mention that making copies is what is already done in
situations where the OS doesn't support it, I can't see why you wouldn't
do that here.

> thanks,
> Pádraig.