bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FYI: bug-fix: cp would fail to write through a dangling symlink


From: Jim Meyering
Subject: Re: FYI: bug-fix: cp would fail to write through a dangling symlink
Date: Wed, 13 Jun 2007 23:38:04 +0200

Paul Eggert <address@hidden> wrote:

> Jim Meyering <address@hidden> writes:
>
>> However, I don't like using canonicalize_filename_mode, partly
>> for its internal "xmalloc".  Technically, copy.c aspires to "librarihood",
>> so it is not supposed to exit on OOM errors, but there is precedent there,
>> and I'm not going to fix *that* right now.
>> Also, it would be subject to the PATH_MAX name length limitation.
>> Another thing not to like: it may use xgetcwd.  Here, we generally
>> don't need the entire absolute name.
>
> Yes, it's total overkill for this application.  Another thing: we
> don't need to resolve internal symlinks, just the last one.

Why would we want to resolve *any* of them, if we can get
the dir-fd, ent-name pair I mentioned?

>> FYI, here's the canonicalize_filename_mode-based solution:
>
> That patch is not quite right, since the CAN_ALL_BUT_LAST flag that I

Hmm... I did at least try to test it.  And it seemed to pass.
I confess I spent very little time on it, so maybe the test is wrong, too.
Will investigate tomorrow.

> suggested earlier turns out to be wrong; we need CAN_MISSING.  But in
> rereading the code I see there's a more systematic problem here.
>
> POSIX says that -H -L -P etc affect only source symlinks; destination
> symlinks are always followed.  (Ouch! maybe we need an option to
> override this, but right now let's just get the standard behavior
> working.)  And yet in several places 'cp' refuses to follow symlinks
> in the destination, e.g., it uses lstat where it should use stat.
>
> Fixing this carefully will require a bit of thinking; I am a bit
> stressed for time right now so it may be a couple of days.  Some of my
> earlier comments about looking at x->dereference were wrong, but they

Ahhh.  I'm relieved.  I wondered about that one (seemed backwards),
but didn't make time to investigate.

> were based on some existing coreutils code that I think is wrong in
> this area as well.

Oh!  Then I'll hunt for it tomorrow if you don't tell first.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]