On 2021/02/25 13:28, Neal Gompa wrote:
With /bin being a symlink to /usr/bin, everything should work the same anyway. It's transparent to scripts. It works this way in Fedora, Ubuntu, macOS, Solaris, and others too.
um... Assume I have shell 'mash' in the new location /usr/bin/mash:
ll /usr/bin/mash -rwxr-xr-x 1 1284320 May 18 2018 /usr/bin/mash*
Now I create my transparent symlink:
sudo ln -s /usr/bin bn ll /bn lrwxrwxrwx 1 8 Mar 1 02:50 /bn -> /usr/bin/ ll bn lrwxrwxrwx 1 8 Mar 1 02:50 bn -> /usr/bin/ ll /bn/mash -rwxr-xr-x 1 1284320 May 18 2018 /bn/mash*
ok, now I want to delete /bn/mash
safe-rm /bn/mash /usr/bin/safe-rm: no symlinks allowed in the path of /bn/mash
Explain to me how vendors checking for symlinks in file path won't be able to detect such and won't have an issue with ignoring something generally regarded as insecure. That suse-makers believe such a symlink is transparent and secure and that Suse should do it because everyone else is doing it is more than a little worrisome. Certain it lends support to the idea of not having a 'standard' system.
It isn't until it is. If you're doing custom kernels with everything built into a blob, you don't need it.
A blob? My standard vanilla kernel has # zgrep =m$ /proc/config.gz |wc -l 538 538 modules with # wc -l /proc/modules 45 45 of them currently loaded
lsmod|wc 46 155 167 46 currently loaded
If you don't care about ramfs based rescue environments, you don't need it.
My entire system is a rescue environment since things break fairly often. I.e. a ramfs can't hold everything needed and even if it did, why copy it into a ram-based block-dev? If you can read your ram-device, then you can read your sys files. Like someone else said, you have your rescue system on root. *Until recently* when I replace my hard disks, 'usr' was on a separate partition. But the system boot/bringup files were in /bin,lib,lib64, etc... one of the first tasks that init did was mount /usr: cd /etc/rc.d/boot.d Ishtar:/etc/rc.d/boot.d# ls -L S* S01boot.sysctl* S01boot.usr-mount* S02boot.udev* S04boot.lvm* S05boot.clock* S06boot.localnet* S11boot.localfs* S13boot.klog* S13boot.lvm_monitor* S13boot.swap* S13setserial* S14boot.isapnp* S14boot.ldconfig* S30boot.assign_netif_names* S50boot.cgroup* S50boot.create_devs* S50boot.sys_settings* S50boot.sysstat* If you evacuate all files to /usr/bin, of course there's a better argument for a ramdisk, but its still not needed as your rescue disk can be a separate partition on your root disk, or a rescue-image in a file on your boot disk. But deciding what limited rescue files go on a ram disk and copying it to ram first, vs. having your entire /bin+/lib dirs be your 'rescue resources' -- why go the extra step of creating a limited rescue disk vs booting native. And the most basic level of rescue: init=/bin/bash Will that work if bash is a symlink? It certainly wouldn't if my /usr was a separate partition like it used to be.