Puncte:1

Cum poate un fișier să fie vizibil pentru un utilizator obișnuit, dar inexistent pentru root?

drapel de

Am pus această întrebare ieri, dar a fost marcată ca duplicat și închisă din cauza contextului său, deoarece se credea că este o întrebare X/Y, în timp ce eram doar interesat de chestiunea generală a „cum ar putea fi aceasta”, deoarece cercetările personale (pe acest site, precum și pe internet) nu au returnat nimic și aș dori să aflu mai multe despre cum să detectez și să rezolv acest tip de problemă particulară.

Deci, fără niciun context, ieri am găsit câteva fișiere pe unul dintre serverele noastre Debian, care erau vizibile pentru un utilizator obișnuit, dar nu pentru rădăcină, deși sunt deținute de rădăcină.

A încercat o mulțime de comenzi pe acele fișiere și orice aș încerca, utilizator tratează fișierele ca fișiere obișnuite, dar rădăcină reacționează ca și cum acele fișiere pur și simplu nu ar exista în primul rând (dar nu le pot suprascrie totuși). Acestea sunt NU fișiere cu puncte.

Iată rezultatele acestor comenzi:

La fel de utilizator

utilizator@debian:/tmp$ grupuri
utilizator cdrom dischetă audio dip video plugdev netdev

utilizator@debian:/tmp$ pwd
/tmp

utilizator@debian:/tmp$ ls -lai
total 320
1048577 drwxrwxrwt 11 rădăcină rădăcină 4096 sept 7 13:04 .
      2 drwxr-xr-x 23 root root 4096 Sep 6 17:34 ..
5901230 -rw-r----- 1 rădăcină rădăcină 0 7 septembrie 12:59 invisible_file
<alte_fișiere>

utilizator@debian:/tmp$ atinge fișierul_invizibil
touch: nu se poate atinge „invisible_file”: permisiunea refuzată

utilizator@debian:/tmp$ rm fişier_invizibil
rm: eliminați fișierul gol obișnuit protejat la scriere „fișier_invizibil”? y
rm: nu se poate elimina „fișierul_invizibil”: operațiunea nu este permisă

utilizator@debian:/tmp$ stat fişier_invizibil
  Fișier: fișier_invizibil
  Dimensiune: 0 Blocuri: 0 Bloc IO: 4096 fișier gol obișnuit
Dispozitiv: 801h/2049d Inode: 5901230 Link-uri: 1
Acces: (0640/-rw-r-----) Uid: ( 0/ rădăcină) Gid: ( 0/ rădăcină)
Acces: 2021-09-07 12:59:54.859124530 +0200
Modificare: 2021-09-07 12:59:54.859124530 +0200
Modificare: 2021-09-07 13:04:03.063441285 +0200
 Naștere: -

utilizator@debian:/tmp$ install /dev/null fișier_invizibil
instalare: nu se poate elimina „fișierul_invizibil”: operațiunea nu este permisă

utilizator@debian:/tmp$ cat fișier_invizibil
cat: invisible_file: Permisiune refuzată

utilizator@debian:/tmp$ găsi /tmp/ -iname „*fișier_invizibil*”
/tmp/fișier_invizibil

utilizator@debian:/tmp$

La fel de rădăcină

root@debian:/tmp# grupuri
rădăcină

root@debian:/tmp# pwd
/tmp

root@debian:/tmp# ls -lai
total 308
1048577 drwxrwxrwt 11 rădăcină rădăcină 4096 sept 7 13:04 .
      2 drwxr-xr-x 23 root root 4096 Sep 6 17:34 ..
<alte_fișiere>

root@debian:/tmp# atingeți fișierul_invizibil

root@debian:/tmp# ls -lai
total 308
1048577 drwxrwxrwt 11 rădăcină rădăcină 4096 sept 7 13:04 .
      2 drwxr-xr-x 23 root root 4096 Sep 6 17:34 ..
<alte_fișiere>

root@debian:/tmp# rm fişier_invizibil
rm: nu poate elimina „fișierul_invizibil”: Nu există un astfel de fișier sau director

root@debian:/tmp# stat fișier_invizibil
stat: nu poate stat „fișier_invizibil”: Nu există un astfel de fișier sau director

root@debian:/tmp# instalează /dev/null fișier_invizibil
instalare: nu se poate crea fișierul obișnuit „fișier_invizibil”: nu există un astfel de fișier sau director

root@debian:/tmp# cat fișier_invizibil
cat: invisible_file: Nu există un astfel de fișier sau director

root@debian:/tmp# găsi /tmp/ -iname „*fișier_invizibil*”

root@debian:/tmp#

Observați că chiar și în ls comanda numărul total de blocuri utilizate este diferit, diferența corespunzătoare fişier_invizibil mărimea.

Singura modalitate prin care pot suprascrie fișierul este prin crearea unui fișier cu alt nume (și chiar alte permisiuni) și ca rădăcină, mv s-a terminat fişier_invizibil, dar fişier_invizibil continuă să fie ascuns pentru rădăcină.

Întrebarea mea este: cum, în lumea Linux, se poate face ca root să ignore complet unele fișiere obișnuite ca și cum nu ar fi fost acolo, ca în cazul meu? Și cum aș putea investiga problema, să fac acele fișiere vizibile din nou și să mă asigur că nu există alte fișiere invizibile de root?

EDITAȚI | × :

Iată montură ieșire, nu îmi arată nimic special:

root@debian:~# mount
sysfs pe /sys tip sysfs (rw,nosuid,nodev,noexec,relatime)
proc pe /proc tip proc (rw,nosuid,nodev,noexec,relatime)
udev pe /dev tip devtmpfs (rw,nosuid,relatime,size=4078644k,nr_inodes=1019661,mode=755)
devpts pe /dev/pts tip devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs pe /run tip tmpfs (rw,nosuid,noexec,relatime,size=817960k,mode=755)
/dev/sda1 on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)
securityfs pe /sys/kernel/security tip securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs pe /dev/shm tip tmpfs (rw,nosuid,nodev)
tmpfs pe /run/lock tip tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs pe /sys/fs/cgroup tip tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup pe /sys/fs/cgroup/systemd tip cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore pe /sys/fs/pstore tip pstore (rw,nosuid,nodev,noexec,relatime)
cgroup pe /sys/fs/cgroup/devices tip cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup pe /sys/fs/cgroup/net_cls, net_prio tip cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup pe /sys/fs/cgroup/pids tip cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup pe /sys/fs/cgroup/cpu,cpuacct tip cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup pe /sys/fs/cgroup/memory tip cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup pe /sys/fs/cgroup/cpuset tip cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup pe /sys/fs/cgroup/perf_event tip cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup pe /sys/fs/cgroup/blkio tip cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup pe /sys/fs/cgroup/freezer tip cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
systemd-1 pe /proc/sys/fs/binfmt_misc tip autofs (rw,relatime,fd=35,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=9463)
hugetlbfs pe /dev/hugepages tip hugetlbfs (rw,relatime)
debugfs pe /sys/kernel/debug tip debugfs (rw,relatime)
mqueue pe /dev/mqueue tip mqueue (rw,relatime)
tmpfs pe /run/user/1000 tip tmpfs (rw,nosuid,nodev,relatime,size=817956k,mode=700,uid=1000,gid=1000)
binfmt_misc pe /proc/sys/fs/binfmt_misc tip binfmt_misc (rw,relatime)

Ieșirea de fsck -nf este urmatorul:

root@debian:~# fsck -nf
fsck de la util-linux 2.29.2
e2fsck 1.43.4 (31-ian-2017)
Avertizare! /dev/sda1 este montat.
Avertisment: se omite recuperarea jurnalului deoarece se face o verificare a sistemului de fișiere numai pentru citire.
Pasul 1: Verificarea inodurilor, blocurilor și dimensiunilor
Inodul șters 524799 are zero dtime. Remediere? Nu

S-au găsit inode care făceau parte dintr-o listă conexă orfană coruptă. Remediere? Nu

Inodul 1441794 a făcut parte din lista de inoduri orfane. IGNORAT.
Pasul 2: Verificarea structurii directoarelor
Pasul 3: Verificarea conectivității directorului
Pasul 4: Verificarea numărului de referințe
Pasul 5: Verificarea informațiilor rezumate ale grupului
Blocați diferențele bitmap: -(11108512--11108538)
Remediere? Nu

Blocurile gratuite sunt greșite (16886612, numărate=16857986).
Remediere? Nu

Diferențele bitmap inod: -524799 -1441794
Remediere? Nu

Numărarea inodurilor libere este greșită (5867140, numărate=5866555).
Remediere? Nu


/dev/sda1: ********** AVERTISMENT: Sistemul de fișiere are încă erori **********

/dev/sda1: 162172/6029312 fișiere (0,3% necontigue), 7230636/24117248 blocuri
root@Confluence:~#

În sfârșit am reușit să rulez un full fsck pe sistemul de fișiere. A corectat erorile afișate mai sus, dar fără rezultat, deoarece fișierele sunt încă invizibile.

drapel ng
`mount` spune ceva special despre `/tmp`? Cu alte cuvinte, puteți detalia structura sistemului de fișiere a sistemului? De asemenea, sunt curios ce s-ar întâmpla dacă l-ai `fsck`; poate e corupt?
mbernard avatar
drapel de
@Halfgaar Ieșirea lui `mount` este aceeași pentru `root` sau `user` și nu pare să arate nimic referitor la `/tmp`. Îmi voi actualiza postarea cu rezultatul menționat.
mbernard avatar
drapel de
@Halfgaar Mi-am actualizat răspunsul cu ceea ce s-a întâmplat cu un „fsck”. Nu a făcut nimic, din păcate.
drapel ng
Ai rulat din nou fsck? Am întâlnit probleme înainte ca a trebuit să-l rulez în mod repetat până când toate erorile au dispărut.
mbernard avatar
drapel de
@Halfgaar Îmi pare rău, nu m-am obișnuit cu acel site și nu am văzut că am primit un răspuns de la tine. Într-adevăr, am rulat `fsck` de mai multe ori. S-a spus că nu mai au fost erori după acele prime.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.