why does GNU/Nano always have to access files via the abs path? - Page 1
Forum section: electronics / general

author: DiTBho
author_rank: Super Contributor
timestamp: May 29, 2024, 06:25:35 pm
content: so today I noticed this strange thing via strace-like tool.Code:# nano test.txtCode:...accessing "/home/DiTBho/exp14/test.txt"...Code:open [/etc/ld.so.cache] ... as ??? flags=0x00088000open [/lib/libncursesw.so.6] ... as ??? flags=0x00088000open [/lib/libtinfow.so.6] ... as ??? flags=0x00088000open [/lib/libc.so.6] ... as ??? flags=0x00088000open [/usr/lib/locale/locale-archive] ... as ??? flags=0x00088000open [/etc/terminfo/x/xterm] ... as ??? flags=0x00008000open [/etc/nanorc] ... as ??? flags=0x00008000open [/usr/share/nano] ... as ??? flags=0x00098800open [/usr/lib/gconv/gconv-modules.cache] ... as readopen [/usr/share/nano/ada.nanorc] ... as ??? flags=0x00008000open [/usr/share/nano/asm.nanorc] ... as ??? flags=0x00008000open [/usr/share/nano/autoconf.nanorc] ... as ??? flags=0x00008000open [/usr/share/nano/awk.nanorc] ... as ??? flags=0x00008000open [/usr/share/nano/c.nanorc] ... as ??? flags=0x00008000open [/usr/share/nano/changelog.nanorc] ... as ??? flags=0x00008000open [/usr/share/nano/cmake.nanorc] ... as ??? flags=0x00008000open [/usr/share/nano/css.nanorc] ... as ??? flags=0x00008000open [/usr/share/nano/default.nanorc] ... as ??? flags=0x00008000open [/usr/share/nano/elisp.nanorc] ... as ??? flags=0x00008000open [/usr/share/nano/email.nanorc] ... as ??? flags=0x00008000open [/usr/share/nano/fortran.nanorc] ... as ??? flags=0x00008000open [/usr/share/nano/gentoo.nanorc] ... as ??? flags=0x00008000open [/usr/share/nano/go.nanorc] ... as ??? flags=0x00008000open [/usr/share/nano/groff.nanorc] ... as ??? flags=0x00008000open [/usr/share/nano/guile.nanorc] ... as ??? flags=0x00008000open [/usr/share/nano/haskell.nanorc] ... as ??? flags=0x00008000open [/usr/share/nano/html.nanorc] ... as ??? flags=0x00008000open [/usr/share/nano/java.nanorc] ... as ??? flags=0x00008000open [/usr/share/nano/javascript.nanorc] ... as ??? flags=0x00008000open [/usr/share/nano/json.nanorc] ... as ??? flags=0x00008000open [/usr/share/nano/lua.nanorc] ... as ??? flags=0x00008000open [/usr/share/nano/makefile.nanorc] ... as ??? flags=0x00008000open [/usr/share/nano/man.nanorc] ... as ??? flags=0x00008000open [/usr/share/nano/markdown.nanorc] ... as ??? flags=0x00008000open [/usr/share/nano/nanohelp.nanorc] ... as ??? flags=0x00008000open [/usr/share/nano/nanorc.nanorc] ... as ??? flags=0x00008000open [/usr/share/nano/nftables.nanorc] ... as ??? flags=0x00008000open [/usr/share/nano/objc.nanorc] ... as ??? flags=0x00008000open [/usr/share/nano/ocaml.nanorc] ... as ??? flags=0x00008000open [/usr/share/nano/patch.nanorc] ... as ??? flags=0x00008000open [/usr/share/nano/perl.nanorc] ... as ??? flags=0x00008000open [/usr/share/nano/php.nanorc] ... as ??? flags=0x00008000open [/usr/share/nano/po.nanorc] ... as ??? flags=0x00008000open [/usr/share/nano/povray.nanorc] ... as ??? flags=0x00008000open [/usr/share/nano/python.nanorc] ... as ??? flags=0x00008000open [/usr/share/nano/ruby.nanorc] ... as ??? flags=0x00008000open [/usr/share/nano/rust.nanorc] ... as ??? flags=0x00008000open [/usr/share/nano/sh.nanorc] ... as ??? flags=0x00008000open [/usr/share/nano/spec.nanorc] ... as ??? flags=0x00008000open [/usr/share/nano/sql.nanorc] ... as ??? flags=0x00008000open [/usr/share/nano/tcl.nanorc] ... as ??? flags=0x00008000open [/usr/share/nano/tex.nanorc] ... as ??? flags=0x00008000open [/usr/share/nano/texinfo.nanorc] ... as ??? flags=0x00008000open [/usr/share/nano/xml.nanorc] ... as ??? flags=0x00008000open [/usr/share/nano/yaml.nanorc] ... as ??? flags=0x00008000open [/usr/share/nano/html.nanorc] ... as ??? flags=0x00008000open [/usr/share/nano/python.nanorc] ... as ??? flags=0x00008000open [/usr/share/nano/sh.nanorc] ... as ??? flags=0x00008000open [/etc/nsswitch.conf] ... as ??? flags=0x00080000open [/etc/passwd] ... as ??? flags=0x00080000open [/home/DiTBho/exp14/test.txt] ... as ??? flags=0x00008000open [/usr/share/locale/locale.alias] ... as ??? flags=0x00080000open [/usr/share/locale/C.UTF8/LC_MESSAGES/nano.mo] ... as readopen [/usr/share/locale/C.utf8/LC_MESSAGES/nano.mo] ... as readopen [/usr/share/locale/C/LC_MESSAGES/nano.mo] ... as readopen [/usr/share/nano/default.nanorc] ... as ??? flags=0x00008000Does it make sense?it seems it's not an option you can change by editing /etc/nanorc or something.

author: ataradov
author_rank: Super Contributor
timestamp: May 29, 2024, 07:07:31 pm
content: Nano source code is less than 20 files. And only one obviously named (files.c) deals with files. You can just look at what it does. For any file name operation it calls get_full_path() to create a canonical version of the file name. There is no option for this.

author: abeyer
author_rank: Frequent Contributor
timestamp: May 29, 2024, 09:00:52 pm
content: This sounds as likely to be an artifact of the tool you're using, as it is to be related to nano... but you don't actually tell us what tool, or why you even think this wouldn't be expected, or what you think you could do about a tracing tool's output from your nanorc.

author: ataradov
author_rank: Super Contributor
timestamp: May 29, 2024, 09:03:37 pm
content: How is this a tool artifact when the nano is coded to use full paths? Why they did it this way is up to them, I doubt there is a real way to find that out.

author: DiTBho
author_rank: Super Contributor
timestamp: May 30, 2024, 01:54:46 am
content: Quote from: ataradov on May 29, 2024, 07:07:31 pmI asked if this makes sense!!! Does it? and if so why?Going to hack it, because e.g { vi, vim, neovim, joe } don't do that.

author: ejeffrey
author_rank: Super Contributor
timestamp: May 30, 2024, 04:00:39 am
content: Why do you care? Patching an editor just because you don't like how the strace output looks is insane behavior even for you. If it breaks something then you can at least ask whether the conditions in which it breaks are sensible.I'm not sure about nano, but I can think of a few reasons why a program might do this.The most obvious reason would be if they are going to save the filename (not just the file descriptor) for later use, but might execute chdir in the interim. Editors store filenames so that they can rename files to backups and create new versions, and they might allow the user to change directory in order to run shell commands with system().Another would be if the program needs to perform input validation on the path. For instance if the program is run with elevated privileges and restricts access to certain paths. In that case it might be important to canonicalize the path either for the check itself, or to protect against symlink and rename race conditions. Actually, looking at the nano source code, there is some stuff about a "confinement" directory that prevents writing to directories other than the one specified. I'd guess this might have been used in the 90s when it was common to give people restricted shells that could access a few pre-set functions but supposedly (they were never very leak tight) not have full access.

author: DiTBho
author_rank: Super Contributor
timestamp: May 30, 2024, 01:07:52 pm
content: Quote from: ejeffrey on May 30, 2024, 04:00:39 amFor what I'm doing(1), the fact that Nano forces an absolute path even when you want to edit a local file creates a big problem for me.I can also clone Nano source and ebuild into an Overlay, edit it, hacket it to remove that part that forces absolute paths, and re-package it.Portage: app/nano editorOverlyay: app-editor/my-nano (collision: will replace { /usr/bin/nano, /usr/share/nano, /etc/nanorc } )In the end it's 1 hour of work. It's why Nano is done this way that I don't get(1) sort of custom and light "sandbox" ... long story on the why.Quote from: ejeffrey on May 30, 2024, 04:00:39 amI also wrote an analysis tool, similar to Strace. I noticed that if you edit a file with vi/vim, it creates two temporary working files.So there are editors for whom this possibility must also be left open, or in any case somehow managed.I was hoping that things would be a little simpler, but instead I have to use a lot more tricks, some of which are very dirty.

author: ejeffrey
author_rank: Super Contributor
timestamp: May 30, 2024, 04:12:50 pm
content: QuoteNote that nano already has code to detect if it's unable to find or use the absolute path, such as if intermediate directories lack permissions. It does fall back to relative paths then.It's not a difficult change to remove this for sure, but I question the validity of any sandboxing system that can't get pathname handling correct. get_full_path doesn't do anything particularly weird that could be done by any other program or the user.Also get_real_path does tilde expansion like the shell, which allows people to visit files with ~/myfile.txt from inside the editor, not just the command line. If you want to allow that, make sure to keep that part of it when you bypass the rest get_full_path.

author: Nominal Animal
author_rank: Super Contributor
timestamp: May 30, 2024, 04:38:06 pm
content: I suppose history is to blame.You see,nanowas a replacement forpicoused in thepineemail client. Using absolute paths for the mailbox files allows safer lock file support and isn't susceptible to same-process working-directory shenanigans. (I usedpineand thenalpinefor, uh, almost two decades for my email.)Nowadays we useopenat()(keeping a reference file descriptor open for the target directory;openat()using that as the working directory reference instead of the current working directory), but it was first introduced in FreeBSD 8.0 in 2005 and in Linux kernel 2.6.16 in 2006, and thus not early enough fornano.