Как файл может быть виден обычному пользователю, но не существовать для root?
Я задал этот вопрос вчера, но он был помечен как дубликат и закрыт из-за его контекста, так как считалось, что это вопрос X/Y, тогда как меня просто интересовал общий вопрос «как это могло быть», как мой личное исследование (на этом веб-сайте, а также в Интернете) ничего не дало, и я хотел бы узнать больше о том, как обнаружить и решить такую специфическую проблему.
Итак, без какого-либо контекста, вчера я обнаружил на одном из наших серверов Debian несколько файлов, которые были видны обычному пользователю, но не видны , несмотря на то, что они принадлежали .
Он испробовал множество команд для этих файлов, и что бы я ни пробовал, он воспринимает файлы как обычные файлы, но реагирует так, как будто этих файлов вообще не существует (но, тем не менее, не может их перезаписать). Это НЕ точечные файлы.
Вот результаты этих команд:
Какuser
user@debian:/tmp$ groups
user cdrom floppy audio dip video plugdev netdev
user@debian:/tmp$ pwd
/tmp
user@debian:/tmp$ ls -lai
total 320
1048577 drwxrwxrwt 11 root root 4096 Sep 7 13:04 .
2 drwxr-xr-x 23 root root 4096 Sep 6 17:34 ..
5901230 -rw-r----- 1 root root 0 Sep 7 12:59 invisible_file
<other_files>
user@debian:/tmp$ touch invisible_file
touch: cannot touch 'invisible_file': Permission denied
user@debian:/tmp$ rm invisible_file
rm: remove write-protected regular empty file 'invisible_file'? y
rm: cannot remove 'invisible_file': Operation not permitted
user@debian:/tmp$ stat invisible_file
File: invisible_file
Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: 801h/2049d Inode: 5901230 Links: 1
Access: (0640/-rw-r-----) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2021-09-07 12:59:54.859124530 +0200
Modify: 2021-09-07 12:59:54.859124530 +0200
Change: 2021-09-07 13:04:03.063441285 +0200
Birth: -
user@debian:/tmp$ install /dev/null invisible_file
install: cannot remove 'invisible_file': Operation not permitted
user@debian:/tmp$ cat invisible_file
cat: invisible_file: Permission denied
user@debian:/tmp$ find /tmp/ -iname "*invisible_file*"
/tmp/invisible_file
user@debian:/tmp$
Как
root@debian:/tmp# groups
root
root@debian:/tmp# pwd
/tmp
root@debian:/tmp# ls -lai
total 308
1048577 drwxrwxrwt 11 root root 4096 Sep 7 13:04 .
2 drwxr-xr-x 23 root root 4096 Sep 6 17:34 ..
<other_files>
root@debian:/tmp# touch invisible_file
root@debian:/tmp# ls -lai
total 308
1048577 drwxrwxrwt 11 root root 4096 Sep 7 13:04 .
2 drwxr-xr-x 23 root root 4096 Sep 6 17:34 ..
<other_files>
root@debian:/tmp# rm invisible_file
rm: cannot remove 'invisible_file': No such file or directory
root@debian:/tmp# stat invisible_file
stat: cannot stat 'invisible_file': No such file or directory
root@debian:/tmp# install /dev/null invisible_file
install: cannot create regular file 'invisible_file': No such file or directory
root@debian:/tmp# cat invisible_file
cat: invisible_file: No such file or directory
root@debian:/tmp# find /tmp/ -iname "*invisible_file*"
root@debian:/tmp#
Обратите внимание, что даже вls
команда, общее количество используемых блоков различно, разница соответствует размеру.
Единственный способ перезаписать файл — создать файл с другим именем (и даже с другими разрешениями) и в качестве ,mv
все закончилось, ноinvisible_file
продолжает быть скрытым отroot
.
Мой вопрос: как в мире Linux можно заставить root полностью игнорировать некоторые обычные файлы, как если бы их вообще не было, как в моем случае? И как я могу расследовать этот вопрос, снова сделать эти файлы видимыми и быть уверенным, что нет других невидимых файлов для root?
РЕДАКТИРОВАТЬ :
Вотmount
вывод, он не показывает ничего особенного для меня:
root@debian:~# mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=4078644k,nr_inodes=1019661,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=817960k,mode=755)
/dev/sda1 on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=35,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=9463)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=817956k,mode=700,uid=1000,gid=1000)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
Выходfsck -nf
следующее:
root@debian:~# fsck -nf
fsck from util-linux 2.29.2
e2fsck 1.43.4 (31-Jan-2017)
Warning! /dev/sda1 is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
Pass 1: Checking inodes, blocks, and sizes
Deleted inode 524799 has zero dtime. Fix? no
Inodes that were part of a corrupted orphan linked list found. Fix? no
Inode 1441794 was part of the orphaned inode list. IGNORED.
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences: -(11108512--11108538)
Fix? no
Free blocks count wrong (16886612, counted=16857986).
Fix? no
Inode bitmap differences: -524799 -1441794
Fix? no
Free inodes count wrong (5867140, counted=5866555).
Fix? no
/dev/sda1: ********** WARNING: Filesystem still has errors **********
/dev/sda1: 162172/6029312 files (0.3% non-contiguous), 7230636/24117248 blocks
root@Confluence:~#
Я наконец-то смог запустить полнуюfsck
в файловой системе. Он исправил указанные выше ошибки, но безрезультатно, поскольку файлы по-прежнему невидимы.