GNU bug report logs - #28264
Accessing source directory through symlink produces false warnings

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 28264 in the body.
You can then email your comments to 28264 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #3 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: submit <at> debbugs.gnu.org
Subject: Accessing source directory through symlink produces false warnings
Date: Mon, 28 Aug 2017 14:25:20 -0400

Package: emacs
Version: 26.0.50

Current master (cd0360f) on rhel7.

Emacs sources are in (eg) /tmp/emacs/git/master
cd ~
ln -s /tmp/emacs/git/master
~/master/src/emacs -Q

This results in the following new, spurious warnings:
    
    Warning: arch-dependent data dir '/:/tmp/emacs/git/master/lib-src/':
       No such file or directory
    Warning: Lisp directory '/:/tmp/emacs/git/master/lisp':
       No such file or directory
    
I would suspect recent changes to file name / symlink handling.

Message #10 received at 28264-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Glenn Morris <rgm <at> gnu.org>, 28264-done <at> debbugs.gnu.org
Cc: Michael Albinus <michael.albinus <at> gmx.de>
Subject: Re: bug#28264: Accessing source directory through symlink produces
 false warnings
Date: Mon, 28 Aug 2017 21:57:15 -0700

[Message part 1 (text/plain, inline)]

Thanks for the bug report. I reproduced the problem and installed the attached 
patch to fix it. It strikes me, though, that the code still won't work in other 
cases (e.g., symlinks containing ":"), and that Emacs probably has other 
instances of confusion between how it treats symlinks and how the OS treats 
them. I'll CC: this to Michael to give him a heads-up about this particular 
issue, as I'm not really up to speed on magic file names.

[0001-Silence-false-alarms-for-symlinks-to-sources.patch (text/x-patch, attachment)]

Message #13 received at 28264 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Glenn Morris <rgm <at> gnu.org>, 28264 <at> debbugs.gnu.org
Subject: Re: bug#28264: Accessing source directory through symlink produces
 false warnings
Date: Tue, 29 Aug 2017 22:41:51 +0200

Paul Eggert <eggert <at> cs.ucla.edu> writes:

Hi Paul,

> Thanks for the bug report. I reproduced the problem and installed the
> attached patch to fix it. It strikes me, though, that the code still
> won't work in other cases (e.g., symlinks containing ":"), and that
> Emacs probably has other instances of confusion between how it treats
> symlinks and how the OS treats them. I'll CC: this to Michael to give
> him a heads-up about this particular issue, as I'm not really up to
> speed on magic file names.

This special problem does not seem to affect Tramp, tramp-tests tell.

However, the following code is unclear to me:

> +	(concat "/:" file))

What, if file is already quoted? Shouldn't this be

        (file-name-quote file)

Note, that a similar problem I have fixed some days ago in commit
cc7530cae0.

Best regards, Michael.

Message #16 received at 28264 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: Glenn Morris <rgm <at> gnu.org>, 28264 <at> debbugs.gnu.org
Subject: Re: bug#28264: Accessing source directory through symlink produces
 false warnings
Date: Tue, 29 Aug 2017 19:20:47 -0700

[Message part 1 (text/plain, inline)]

Michael Albinus wrote:

> This special problem does not seem to affect Tramp, tramp-tests tell.

The problem I was thinking of does not seem to be covered by Tramp tests. If, 
for example, I do these shell commands:

$ ln -s "../penguin:motd" /tmp/foo
$ ls -l /tmp/foo
lrwxrwxrwx 1 eggert eggert 15 Aug 29 19:00 /tmp/foo -> ../penguin:motd

then (file-truename "/tmp/foo") returns "/penguin:motd" which is not /tmp/foo's 
true name as far as Emacs file-oriented commands are concerned. Admittedly this 
is an improvement over Emacs 25.2 where the same file-truename call ssh'es into 
penguin to resolve the name, which is a clear security issue. Still, it doesn't 
seem right, if file-truename is expected to quote its result if necessary.

Sorry about all this confusion, but I do not know the general principle that 
Emacs is supposed to be using with file names, and to some extent I fear that 
there isn't one alas.

> However, the following code is unclear to me:
> 
>> +	(concat "/:" file))
> 
> What, if file is already quoted? Shouldn't this be
> 
>          (file-name-quote file)

Quite possibly, and I'll take your word for it. I installed the attached.

[0001-Prefer-file-name-quote-to-concat.patch (text/x-patch, attachment)]

Message #19 received at 28264 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Glenn Morris <rgm <at> gnu.org>, 28264 <at> debbugs.gnu.org
Subject: Re: bug#28264: Accessing source directory through symlink produces
 false warnings
Date: Wed, 30 Aug 2017 10:37:05 +0200

Paul Eggert <eggert <at> cs.ucla.edu> writes:

Hi Paul,

> The problem I was thinking of does not seem to be covered by Tramp
> tests. If, for example, I do these shell commands:
>
> $ ln -s "../penguin:motd" /tmp/foo
> $ ls -l /tmp/foo
> lrwxrwxrwx 1 eggert eggert 15 Aug 29 19:00 /tmp/foo -> ../penguin:motd
>
> then (file-truename "/tmp/foo") returns "/penguin:motd" which is not
> /tmp/foo's true name as far as Emacs file-oriented commands are
> concerned.

It is. "/penguin:motd" is not a remote file name by default (it would be
only with Tramp's simplified syntax). But this is rather academical;
"/penguin:motd:" would be a remote file name. So let's continue with
this example.

I've changed the link:

# ls -l /tmp/foo
lrwxrwxrwx 1 albinus albinus 16 Aug 30 10:10 /tmp/foo -> ../penguin:motd:

The problem in returning a remote file name still exists, maybe you
could check your change, again? (file-truename "/tmp/foo") goes remote
to "/penguin:motd:".

For Tramp, we have

(file-truename "/ssh::/tmp/foo") => "/ssh:hostname:/penguin:motd:"

This is not wrong, but I'd prefer to get its quoted variant
"/ssh:hostname:/:/penguin:motd:". Will work on this.

And I'll add your test to tramp-tests.el.

Best regards, Michael.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.