From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id YKNsK4ItW2VkWgAAauVa8A:P1 (envelope-from ) for ; Mon, 20 Nov 2023 10:57:22 +0100 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id YKNsK4ItW2VkWgAAauVa8A (envelope-from ) for ; Mon, 20 Nov 2023 10:57:22 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 3467017398 for ; Mon, 20 Nov 2023 10:57:22 +0100 (CET) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=G7I47aID; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1700474242; a=rsa-sha256; cv=none; b=pOnbkyi+8SNHktJOvhUt15s2cXrmNpz88Dgdb7zgFrfTxg45yPlAApI25VwYFrbEiPxACu YuGKXWVYSUiUXpCE40Oa3/BiHGGvSLTBQwU8RK7aSg+B2wL3hPlmgYk6GRZHHWwnd/rtY6 WTN+ZwHx880wJU7V1x19kNYfWYKReI6wkY65rIJsT0vqjhrDToRQYj2aYeo/CitjVVDkW7 311IAPIO9nXXKMMD+7toO8aSohdN0UmXcuYcoXaB57/0DBjCoU+eAZf1BaJcfmrzuYHa9Y RaDlEB3oTLm7p+Ir3SX2Zc2awRebUwAyG7WK5ylubiRwp36rJla+C0aknITZeA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1700474242; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=jOVXWIh70bpDyzi+wc4YjCRIaLWr3AfeTX73TB9CllU=; b=kuB+P2I4xnMsmvoyPhm74+R7HD2hQYH8e4ajyWyNsokmoff5SFQSUSKHjvETqPiZudXxgs eGTrBfYAOtt9FdlhRvA3szds0dx2F7oHom+YmYyGWnrFh6BPPoLVhFqnPMDZ6wb3zThPaV HxhwvPL066pph4LUMe8KyTQi5oULL/SdEFQgjJ2JY/PsMsRGi5ZcL5UL2g3nw7SrJ4pdzY MAL/HuaazzSdxxba+DGei2WlhXUBgwvtaICpCrpTphO1m+i3XmSzap/Ay4YV47wIm8R0+5 BrcxlEUbUK4OjbzacQc5LztuGVELeTJnV+kcYMj52cpFErjLDES1hKD0if+mnA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=G7I47aID; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r5118-0000tO-8x; Mon, 20 Nov 2023 04:56:34 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r5116-0000sq-PZ for emacs-orgmode@gnu.org; Mon, 20 Nov 2023 04:56:32 -0500 Received: from mail-yw1-x1131.google.com ([2607:f8b0:4864:20::1131]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r5113-0006h1-E8 for emacs-orgmode@gnu.org; Mon, 20 Nov 2023 04:56:31 -0500 Received: by mail-yw1-x1131.google.com with SMTP id 00721157ae682-5cacfd8ef23so3747387b3.2 for ; Mon, 20 Nov 2023 01:56:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1700474187; x=1701078987; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=jOVXWIh70bpDyzi+wc4YjCRIaLWr3AfeTX73TB9CllU=; b=G7I47aIDGXd24iHFbDeEpuxyTvdmn8T5Ei5ysMka08SEDLazbTqXmtiTrDhTpKWQna dKTDPqKhYObWA3TAZlJq+5ALoMyixpXTavLAeErHKCLkPXYbvTVIvxJgEqlwzab4funP MfPU4iE6ndglF8eLhQRJ4jadmtu1aD+iBecMzvFQgPLmTg8CvloyYgCd/vHLCZyFjbd8 YP24WxYyGMy/xHuqc/5cWAaCBsCHhSNDSeRFqkP/ohy0P4HlKIDOS8wvPrvXitwjXnym DCr9JUkAEyy1BucBSxu/pFjr4uVBQHRc0XWh61qhkwIf16qx+nsQVNLkkvUxzBvPPOyn Ozbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700474187; x=1701078987; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=jOVXWIh70bpDyzi+wc4YjCRIaLWr3AfeTX73TB9CllU=; b=aKgR91ScNfa85ZccnK7cyMX5KyoBYmfbYsqctx38O0r2NsF2+lQIz2dO4xqMQPpTRE wi8AzqE+oLk5iysoqH8GGTp7fvqjcHbF4mCrxRglHSk4btMsUUiYjxQ4DlU2Zylz3H5z adaNO/BwN3EbE7KLiqhpwJzGtzuNhnLPovvuHG/R0jdcf1BRwpepRCeoGof4lVL5dklh Qd+9i5XMM8UvJiwKak+325X56Hsa8ZWm0W7YGIpjgvVncozGRDCb675+d39D0k2yUqP+ 5qxtQRJGpElvb+eCWKDVLQhFMl/+F/5+mYMH2bCn1lDzwY5Aq90yEZf7eaIV8gguG03/ txfQ== X-Gm-Message-State: AOJu0YwapvwZkNGYhrB22iH7D4PBr/syBsrTB+msoQNA7tinxtR7h2Cs vpbOE43IC6Bft+YR+Eu1nZ1vQBr89hsZDmlhxoU= X-Google-Smtp-Source: AGHT+IENvN2/eCSK4CMoPXVN3q3Oc3FHJazkZCwL6KTYX/5zwH+F+bIpcKFOnbxH5eXvjTz9wa74C2bDvSgqc+VDl4c= X-Received: by 2002:a81:4e83:0:b0:5a8:d92b:fbf3 with SMTP id c125-20020a814e83000000b005a8d92bfbf3mr7304805ywb.38.1700474187527; Mon, 20 Nov 2023 01:56:27 -0800 (PST) MIME-Version: 1.0 References: <87wmuu3lh7.fsf@localhost> <87leb9243e.fsf@localhost> In-Reply-To: <87leb9243e.fsf@localhost> From: Cletip Cletip Date: Mon, 20 Nov 2023 10:55:51 +0100 Message-ID: Subject: Re: [BUG] Tangle with symbolic links don't work To: Ihor Radchenko Cc: Max Nikulin , Org Mode List Content-Type: multipart/alternative; boundary="000000000000e5bbfc060a927f93" Received-SPF: pass client-ip=2607:f8b0:4864:20::1131; envelope-from=clement020302@gmail.com; helo=mail-yw1-x1131.google.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Scanner: mx11.migadu.com X-Spam-Score: -9.42 X-Migadu-Queue-Id: 3467017398 X-Migadu-Spam-Score: -9.42 X-TUID: j8hOkXQEh2y6 --000000000000e5bbfc060a927f93 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello ! Sorry to bring up the subject again, but I didn't quite understand what the solution was: should I modify the function ? Is it modified in a new version of org-mode ? Thank you in advance for your response. Le mar. 7 nov. 2023 =C3=A0 12:28, Ihor Radchenko a = =C3=A9crit : > Max Nikulin writes: > > >> 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#protect= ed-symlinks > > Thanks! > > > 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. Th= e > > following citation is unrelated to /tmp, but the same proposed patch ha= s > > an issue with predictable name in /tmp: > > We have to compromise between usability and safety... but probably not > in this case. > > > 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 fo= r > > shared libraries since it allows running application to continue call > > function from the deleted file. > > What we actually use is Elisp API. For export and tangling, we use > `write-region' - it correctly handles TRAMP files with lower-level > details taken care of. > > I can now see that blindly expanding to `file-truename' may not be wise. > > Without `file-truename', the difference between ox.el (that works for > Cletip) and ob-tangle.el is that ob-tangle explicitly deletes the tangle > target before tangling: > > `org-babel-tangle': > > ;; erase previous file > (when (file-exists-p file-name) > (delete-file file-name)) > (write-region nil nil file-name) > (mapc (lambda (mode) (set-file-modes file-name mode)= ) > modes) > > Rather than using `file-truename', we may instead remove the > `delete-file' part. This way, we will not risk changing file modes in > the original files and always modify the symlink, if the tangle target > is an existing symlink. > > > 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. > > It is exactly an answer I expected, actually :) > > -- > Ihor Radchenko // yantar92, > Org mode contributor, > Learn more about Org mode at . > Support Org development at , > or support my work at > --000000000000e5bbfc060a927f93 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello !

Sorry to bring up the subject again, but I = didn't quite understand what the solution was: should I modify the func= tion ? Is it modified in a new version of org-mode ?=C2=A0

Thank you in advance for your response.

Le=C2=A0mar. 7 nov. 2023 = =C3=A0=C2=A012:28, Ihor Radchenko <yantar92@posteo.net> a =C3=A9crit=C2=A0:
Max Nikulin <manikulin@gmail.com&g= t; writes:

>> 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

Thanks!

> 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. T= he
> following citation is unrelated to /tmp, but the same proposed patch h= as
> an issue with predictable name in /tmp:

We have to compromise between usability and safety... but probably not
in this case.

> 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 atomicall= y
> (create a temporary one and rename). The latter way is more suitable f= or
> shared libraries since it allows running application to continue call =
> function from the deleted file.

What we actually use is Elisp API. For export and tangling, we use
`write-region' - it correctly handles TRAMP files with lower-level
details taken care of.

I can now see that blindly expanding to `file-truename' may not be wise= .

Without `file-truename', the difference between ox.el (that works for Cletip) and ob-tangle.el is that ob-tangle explicitly deletes the tangle target before tangling:

`org-babel-tangle':

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0;; erase previous file
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0(when (file-exists-p file-name)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0(delete-file file-name))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0(write-region nil nil file-name)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0(mapc (lambda (mode) (set-file-modes file-name mode)) modes)

Rather than using `file-truename', we may instead remove the
`delete-file' part. This way, we will not risk changing file modes in the original files and always modify the symlink, if the tangle target
is an existing symlink.

> 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.

It is exactly an answer I expected, actually :)

--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,=
or support my work at <https://liberapay.com/yantar92>
--000000000000e5bbfc060a927f93--