Author Topic: why does GNU/Nano always have to access files via the abs path?  (Read 1475 times)

0 Members and 2 Guests are viewing this topic.

Offline DiTBhoTopic starter

  • Super Contributor
  • ***
  • Posts: 4018
  • Country: gb
so today I noticed this strange thing via strace-like tool.
Code: [Select]
# nano test.txt
Code: [Select]
...
accessing "/home/DiTBho/exp14/test.txt"
...
Code: [Select]
open [/etc/ld.so.cache] ... as ??? flags=0x00088000
open [/lib/libncursesw.so.6] ... as ??? flags=0x00088000
open [/lib/libtinfow.so.6] ... as ??? flags=0x00088000
open [/lib/libc.so.6] ... as ??? flags=0x00088000
open [/usr/lib/locale/locale-archive] ... as ??? flags=0x00088000
open [/etc/terminfo/x/xterm] ... as ??? flags=0x00008000
open [/etc/nanorc] ... as ??? flags=0x00008000
open [/usr/share/nano] ... as ??? flags=0x00098800
open [/usr/lib/gconv/gconv-modules.cache] ... as read
open [/usr/share/nano/ada.nanorc] ... as ??? flags=0x00008000
open [/usr/share/nano/asm.nanorc] ... as ??? flags=0x00008000
open [/usr/share/nano/autoconf.nanorc] ... as ??? flags=0x00008000
open [/usr/share/nano/awk.nanorc] ... as ??? flags=0x00008000
open [/usr/share/nano/c.nanorc] ... as ??? flags=0x00008000
open [/usr/share/nano/changelog.nanorc] ... as ??? flags=0x00008000
open [/usr/share/nano/cmake.nanorc] ... as ??? flags=0x00008000
open [/usr/share/nano/css.nanorc] ... as ??? flags=0x00008000
open [/usr/share/nano/default.nanorc] ... as ??? flags=0x00008000
open [/usr/share/nano/elisp.nanorc] ... as ??? flags=0x00008000
open [/usr/share/nano/email.nanorc] ... as ??? flags=0x00008000
open [/usr/share/nano/fortran.nanorc] ... as ??? flags=0x00008000
open [/usr/share/nano/gentoo.nanorc] ... as ??? flags=0x00008000
open [/usr/share/nano/go.nanorc] ... as ??? flags=0x00008000
open [/usr/share/nano/groff.nanorc] ... as ??? flags=0x00008000
open [/usr/share/nano/guile.nanorc] ... as ??? flags=0x00008000
open [/usr/share/nano/haskell.nanorc] ... as ??? flags=0x00008000
open [/usr/share/nano/html.nanorc] ... as ??? flags=0x00008000
open [/usr/share/nano/java.nanorc] ... as ??? flags=0x00008000
open [/usr/share/nano/javascript.nanorc] ... as ??? flags=0x00008000
open [/usr/share/nano/json.nanorc] ... as ??? flags=0x00008000
open [/usr/share/nano/lua.nanorc] ... as ??? flags=0x00008000
open [/usr/share/nano/makefile.nanorc] ... as ??? flags=0x00008000
open [/usr/share/nano/man.nanorc] ... as ??? flags=0x00008000
open [/usr/share/nano/markdown.nanorc] ... as ??? flags=0x00008000
open [/usr/share/nano/nanohelp.nanorc] ... as ??? flags=0x00008000
open [/usr/share/nano/nanorc.nanorc] ... as ??? flags=0x00008000
open [/usr/share/nano/nftables.nanorc] ... as ??? flags=0x00008000
open [/usr/share/nano/objc.nanorc] ... as ??? flags=0x00008000
open [/usr/share/nano/ocaml.nanorc] ... as ??? flags=0x00008000
open [/usr/share/nano/patch.nanorc] ... as ??? flags=0x00008000
open [/usr/share/nano/perl.nanorc] ... as ??? flags=0x00008000
open [/usr/share/nano/php.nanorc] ... as ??? flags=0x00008000
open [/usr/share/nano/po.nanorc] ... as ??? flags=0x00008000
open [/usr/share/nano/povray.nanorc] ... as ??? flags=0x00008000
open [/usr/share/nano/python.nanorc] ... as ??? flags=0x00008000
open [/usr/share/nano/ruby.nanorc] ... as ??? flags=0x00008000
open [/usr/share/nano/rust.nanorc] ... as ??? flags=0x00008000
open [/usr/share/nano/sh.nanorc] ... as ??? flags=0x00008000
open [/usr/share/nano/spec.nanorc] ... as ??? flags=0x00008000
open [/usr/share/nano/sql.nanorc] ... as ??? flags=0x00008000
open [/usr/share/nano/tcl.nanorc] ... as ??? flags=0x00008000
open [/usr/share/nano/tex.nanorc] ... as ??? flags=0x00008000
open [/usr/share/nano/texinfo.nanorc] ... as ??? flags=0x00008000
open [/usr/share/nano/xml.nanorc] ... as ??? flags=0x00008000
open [/usr/share/nano/yaml.nanorc] ... as ??? flags=0x00008000
open [/usr/share/nano/html.nanorc] ... as ??? flags=0x00008000
open [/usr/share/nano/python.nanorc] ... as ??? flags=0x00008000
open [/usr/share/nano/sh.nanorc] ... as ??? flags=0x00008000
open [/etc/nsswitch.conf] ... as ??? flags=0x00080000
open [/etc/passwd] ... as ??? flags=0x00080000
open [/home/DiTBho/exp14/test.txt] ... as ??? flags=0x00008000
open [/usr/share/locale/locale.alias] ... as ??? flags=0x00080000
open [/usr/share/locale/C.UTF8/LC_MESSAGES/nano.mo] ... as read
open [/usr/share/locale/C.utf8/LC_MESSAGES/nano.mo] ... as read
open [/usr/share/locale/C/LC_MESSAGES/nano.mo] ... as read
open [/usr/share/nano/default.nanorc] ... as ??? flags=0x00008000

Does it make sense?  :-//

it seems it's not an option you can change by editing /etc/nanorc or something.
« Last Edit: May 29, 2024, 06:27:12 pm by DiTBho »
The opposite of courage is not cowardice, it is conformity. Even a dead fish can go with the flow
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 11474
  • Country: us
    • Personal site
Re: why does GNU/Nano always have to access files via the abs path?
« Reply #1 on: May 29, 2024, 07:07:31 pm »
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.
Alex
 
The following users thanked this post: SiliconWizard

Offline abeyer

  • Frequent Contributor
  • **
  • Posts: 326
  • Country: us
Re: why does GNU/Nano always have to access files via the abs path?
« Reply #2 on: May 29, 2024, 09:00:52 pm »
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.
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 11474
  • Country: us
    • Personal site
Re: why does GNU/Nano always have to access files via the abs path?
« Reply #3 on: May 29, 2024, 09:03:37 pm »
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.
Alex
 

Offline DiTBhoTopic starter

  • Super Contributor
  • ***
  • Posts: 4018
  • Country: gb
Re: why does GNU/Nano always have to access files via the abs path?
« Reply #4 on: May 30, 2024, 01:54:46 am »
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.

I 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.
The opposite of courage is not cowardice, it is conformity. Even a dead fish can go with the flow
 

Offline ejeffrey

  • Super Contributor
  • ***
  • Posts: 3791
  • Country: us
Re: why does GNU/Nano always have to access files via the abs path?
« Reply #5 on: May 30, 2024, 04:00:39 am »
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.
 

Offline DiTBhoTopic starter

  • Super Contributor
  • ***
  • Posts: 4018
  • Country: gb
Re: why does GNU/Nano always have to access files via the abs path?
« Reply #6 on: May 30, 2024, 01:07:52 pm »
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.

For 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 editor
Overlyay: 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.


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.

I 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.
The opposite of courage is not cowardice, it is conformity. Even a dead fish can go with the flow
 

Offline ejeffrey

  • Super Contributor
  • ***
  • Posts: 3791
  • Country: us
Re: why does GNU/Nano always have to access files via the abs path?
« Reply #7 on: May 30, 2024, 04:12:50 pm »
Quote
(1) sort of custom and light "sandbox" ... long story on the why.

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

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6514
  • Country: fi
    • My home page and email address
Re: why does GNU/Nano always have to access files via the abs path?
« Reply #8 on: May 30, 2024, 04:38:06 pm »
I suppose history is to blame.

You see, nano was a replacement for pico used in the pine email client.  Using absolute paths for the mailbox files allows safer lock file support and isn't susceptible to same-process working-directory shenanigans.  (I used pine and then alpine for, uh, almost two decades for my email.)

Nowadays we use openat() (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 for nano.
 
The following users thanked this post: SiliconWizard


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf