Re: [BUG] Tangle with symbolic links don't work

[Max Nikulin]

On 06/11/2023 23:17, Ihor Radchenko wrote:
> Cletip Cletip writes:
>
> > I have an Org file, test.org, from which I tangle code blocks into test.py.
> > The complication arises because test.py is a symbolic link.

I suggest to change your workflow to not depend on particular means to 
write tangled files. Perhaps you may set tangle directory. Unfortunately 
the description is too concise to figure out if it would be convenient 
enough.

> Max, do you see any pitfalls using `file-truename'?

Sorry, I am not familiar with related code path. That is why I can not 
reason what way to deal with file name is safer.

If there is a world-writable directory in the file path (usually 
$TMPDIR) then `file-truename' is less safe, see 
https://www.kernel.org/doc/html/latest/admin-guide/sysctl/fs.html#protected-symlinks

echo content >/home/ubuntu/tmp/file.txt
ls -l /home/ubuntu/tmp/file.txt
-rw-r--r-- 1 ubuntu ubuntu 8 Nov  7 17:29 /home/ubuntu/tmp/file.txt

ls -l /tmp/ln
lrwxrwxrwx 1 test test 25 Nov  7 17:10 /tmp/ln -> /home/ubuntu/tmp/file.txt

Notice different owner of the symlink.

echo overwrite >/tmp/ln
bash: /tmp/ln: Permission denied

cat /home/ubuntu/tmp/file.txt
content

`file-truename':

echo overwrite>"$(readlink -f /tmp/ln)"
cat /home/ubuntu/tmp/file.txt
overwrite

/usr/sbin/sysctl fs.protected_symlinks
fs.protected_symlinks = 1

In general, I am never sure that Org code follows best practices in 
respect to security in general and in respect to /tmp in particular. The 
following citation is unrelated to /tmp, but the same proposed patch has 
an issue with predictable name in /tmp:

Visuwesh… Re: [BUG] [PATCH] Add yank-media and DND handler. Wed, 27 Sep 
2023 13:59:49 +0530. https://list.orgmode.org/878r8sj9xe.fsf@gmail.com
> That would be quite annoying IMO.  I say we let the user shoot
> themselves in the foot.

Even when /tmp or similar directories are not involved, a proper 
strategy to replace file content should be carefully chosen. E.g. cp(1) 
preserves inode number while install(1) replaces target file atomically 
(create a temporary one and rename). The latter way is more suitable for 
shared libraries since it allows running application to continue call 
function from the deleted file.

I know, it is not an answer you expected from me, but giving a better 
one require to much efforts to read the code and to debug it.