rear rescue over TFTP/NFS fails: Filestructure has wrong permission

[raspel01]

Relax-and-Recover (ReaR) Issue Template

Fill in the following items before submitting a new issue
(quick response is not guaranteed with free support):

• ReaR version ("/usr/sbin/rear -V"):
  Relax-and-Recover 2.6 / Git

• OS version ("cat /etc/os-release" or "lsb_release -a" or "cat /etc/rear/os.conf"):
  No LSB modules are available.
  Distributor ID: Debian
  Description: Debian GNU/Linux 11 (bullseye)
  Release: 11
  Codename: bullseye

• ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):
  cat /etc/rear/local.conf
  OUTPUT=PXE
  OUTPUT_PREFIX_PXE=$HOSTNAME
  BACKUP=NETFS
  BACKUP_URL=nfs://taurus/mnt/filer/tftpboot/rear
  BACKUP_PROG_EXCLUDE=( '/tmp/' '/dev/shm/' "$VAR_DIR/output/" '/var/lib/samba/private/msg.sock/' )

PXE_TFTP_URL=nfs://taurus/mnt/filer/tftpboot/rear
PXE_CONFIG_URL=nfs://taurus/mnt/filer/tftpboot/pxelinux.cfg
PXE_CREATE_LINKS="MAC"
USE_STATIC_NETWORKING=y

• Hardware (PC or PowerNV BareMetal or ARM) or virtual machine (KVM guest or PoverVM LPAR):
  Intel based PC

• System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device):
  x86 compatible

• Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):
  Phoenix/Award Bios, Grub2

• Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe):
  SSD

• Storage layout ("lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,SIZE,MOUNTPOINT" or "lsblk" as makeshift):
  AME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
  sda 8:0 0 111,8G 0 disk
  ├─sda1 8:1 0 27,9G 0 part /
  ├─sda2 8:2 0 1K 0 part
  ├─sda5 8:5 0 4G 0 part [SWAP]
  └─sda6 8:6 0 79,9G 0 part

• Description of the issue (ideally so that others can reproduce it):
  rear rescue over TFTP/NFS fails : Filestructure has wrong permission

On the share pxe use nfs a subdirectory, named with the backuped hostname created with the permission 750.
If you start a rescue via Pxe, it fails like "rear/tardis/tardis.kernel failed No Fiel or Directory"

• Workaround, if any:
  The reason for this behaviour i've found in this file:
  ../output/default/200_make_prefix_dir.sh:mkdir -p $v -m0750 "${opath}" >&2
  If "0750" is changed to "0755" everythings looks good. The rescue is well done

• Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files):

To paste verbatim text like command output or file content,
include it between a leading and a closing line of three backticks like

```
verbatim content
```

[gdha]

@raspel01 nice catch - why not making a pull request for it?

[raspel01]

Ok... Its the first time for me... I'll do my best...

[pcahyna]

I suppose it is due to root squashing? Should the backup be world-readable, actually? I suspect there is some reason behind creating it as 750 and not 755.

[raspel01]

That may be possible... But look in my /etc/exports:
/mnt/filer/tftpboot/rear 10.10.10.0/255.255.255.0(rw,no_root_squash,sync,no_subtree_check,fsid=9)
All my Install-Images on this pxe-boot Server works like this...

[raspel01]

pcahyna: The used tftp-daemon atftpd runs per default as user nobody... Perhabs this is the reason why the directory ../rear// needs to be accessible worldwide...

[pcahyna]

pcahyna: The used tftp-daemon atftpd runs per default as user nobody... Perhabs this is the reason why the directory ../rear// needs to be accessible worldwide...

I see. I would say that before creating a PR, it is needed to determine what actually are the right permissions, because it is far from obvious. Maybe owhership by root:nobody would do the trick?

[pcahyna]

@raspel01 is it a regression, that is, did it work correctly in earlier releases? I suppose that a workaround would be to export the directories with root squashing? But maybe it would lead to other problems.

[raspel01]

You mean, the atftpd should startet with ownership root:nobody? To your second answer: In Version 2.4 it is the same...
But for me is this no question... I have a workaround for my systems. You could close this issue...

[pcahyna]

No, I meant the directory should be owned by root:nobody, maybe. I think it is a real issue and it should stay open. What workaround did you use?

[raspel01]

The directory .../rear//... would created by rear... The script, i point to in this issue, show the mkdir command with the option -m750...

[jsmeix]

I think that directory should be neither world-readable nor world-writable
because it contains confidential data. In particular it may contain
the backup of (almost) all files of the system.
I added a comment via
53ec3f3

As far as I see in in function output_path() in lib/global-functions.sh
that directory can be a local path like $path/${OUTPUT_PREFIX}
or a temporary mount-path like ${BUILD_DIR}/outputfs/${OUTPUT_PREFIX}.

When it is a local path that directory must be neither world-readable nor world-writable.
Off the top of my head I don't know how things behave when it is a temporary mount-path.

[github-actions]

Stale issue message