#2671 Issue closed: rear rescue over TFTP/NFS fails: Filestructure has wrong permission

Labels: minor bug, no-issue-activity

raspel01 opened issue at 2021-08-17 12:27:

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 commented at 2021-08-17 15:44:

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

raspel01 commented at 2021-08-17 17:23:

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

pcahyna commented at 2021-08-17 17:40:

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 commented at 2021-08-17 17:45:

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 commented at 2021-08-17 18:07:

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 commented at 2021-08-17 18:11:

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 commented at 2021-08-17 18:13:

@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 commented at 2021-08-17 18:21:

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 commented at 2021-08-17 18:24:

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 commented at 2021-08-17 18:29:

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

jsmeix commented at 2021-08-31 14:36:

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
https://github.com/rear/rear/commit/53ec3f39dcb50cd10ea752556dc8b273f78c45ef

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 commented at 2021-10-31 02:12:

Stale issue message

[Export of Github issue for rear/rear.]