Autorizzazioni per directory locale Linux come punti interrogativi per non root


8

Va bene, quello è nuovo. Ho visto casi del genere con dispositivi di archiviazione difettosi, con errori nell'archiviazione remota (SAN, NAS), penso di aver visto anche qualcosa di simile causato dalle autorizzazioni di montaggio. Ma è la prima volta che vedo accadere sullo stesso filesystem del mio homedir ...

Sono molto curioso al riguardo ... Che tipo di permisison stanno entrando qui? Sicuramente non monta (sono sullo stesso filesystem ext4), non SELinux, non ACL. Allora cosa ???

Non ricordo come è stata creata questa directory. È probabile che sia stato creato da un qualche tipo di software.

Per me la parte più strana è che alla directory non è nemmeno permesso vedere le sue informazioni o quelle dei suoi genitori (ultimo comando) ...

Linux Mint Sarah

user01@MyPC ~/somedirectory $ ls -l ./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D\:
ls: negaliu pasiekti './deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D:/workspace': Permission denied
viso 0
d????????? ? ? ? ?            ? workspace
user01@MyPC ~/somedirectory $ ls -ld ./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D\:
drw-r--r-- 3 user01 user01 4096 Rgs 27  2016 ./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D:
user01@MyPC ~/somedirectory $ 
user01@MyPC ~/somedirectory $ 
user01@MyPC ~/somedirectory $ ls -l ./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D\:
ls: negaliu pasiekti './deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D:/workspace': Permission denied
viso 0
d????????? ? ? ? ?            ? workspace
user01@MyPC ~/somedirectory $ 
user01@MyPC ~/somedirectory $ 
user01@MyPC ~/somedirectory $ sudo file ./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D\:
./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D:: directory
user01@MyPC ~/somedirectory $ sudo ls -l ./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D\:
viso 4
drwxr-xr-x 3 user01 user01 4096 Rgs 27  2016 workspace
user01@MyPC ~/somedirectory $ sudo stat ./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D\:
  File: './deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D:'
  Size: 4096        Blocks: 8          IO Block: 4096   aplankas
Device: 807h/2055d  Inode: 3937216     Links: 3
Access: (0644/drw-r--r--)  Uid: ( 1000/ user01)   Gid: ( 1000/ user01)
Access: 2017-09-21 12:57:33.990819052 +0300
Modify: 2016-09-27 11:18:38.309775066 +0300
Change: 2017-03-13 14:56:40.960468954 +0200
 Birth: -
user01@MyPC ~/somedirectory $ sudo getfacl ./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D\:
# file: deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D:
# owner: user01
# group: user01
user::rw-
group::r--
other::r--

user01@MyPC ~/somedirectory $ stat ./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D\:
  File: './deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D:'
  Size: 4096        Blocks: 8          IO Block: 4096   aplankas
Device: 807h/2055d  Inode: 3937216     Links: 3
Access: (0644/drw-r--r--)  Uid: ( 1000/ user01)   Gid: ( 1000/ user01)
Access: 2017-09-21 12:57:33.990819052 +0300
Modify: 2016-09-27 11:18:38.309775066 +0300
Change: 2017-03-13 14:56:40.960468954 +0200
 Birth: -
user01@MyPC ~/somedirectory $ stat ./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D\:/workspace
stat: nepavyksta patikrinti './deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D:/workspace': Permission denied
user01@MyPC ~/somedirectory $ sudo stat ./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D\:/workspace
  File: './deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D:/workspace'
  Size: 4096        Blocks: 8          IO Block: 4096   aplankas
Device: 807h/2055d  Inode: 3937217     Links: 3
Access: (0755/drwxr-xr-x)  Uid: ( 1000/ user01)   Gid: ( 1000/ user01)
Access: 2017-09-21 12:58:46.845727190 +0300
Modify: 2016-09-27 11:18:38.309775066 +0300
Change: 2016-12-02 13:56:08.298109826 +0200
 Birth: -
user01@MyPC ~/somedirectory $ stat .
  File: '.'
  Size: 4096        Blocks: 8          IO Block: 4096   aplankas
Device: 807h/2055d  Inode: 3278479     Links: 23
Access: (0755/drwxr-xr-x)  Uid: ( 1000/ user01)   Gid: ( 1000/ user01)
Access: 2017-09-21 09:46:22.102269130 +0300
Modify: 2017-09-20 17:33:04.564009275 +0300
Change: 2017-09-20 17:33:04.564009275 +0300
 Birth: -
user01@MyPC ~/somedirectory $ ll ./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D\:/
ls: negaliu pasiekti './deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D:/workspace': Permission denied
ls: negaliu pasiekti './deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D:/.': Permission denied
ls: negaliu pasiekti './deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D:/..': Permission denied
viso 0
d????????? ? ? ? ?            ? ./
d????????? ? ? ? ?            ? ../
d????????? ? ? ? ?            ? workspace/
user01@MyPC ~/somedirectory $ 

attributi:

user01@MyPC ~/somedirectory $ sudo lsattr ./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D\:/
-------------e-- ./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D:/workspace
user01@MyPC ~/somedirectory $ sudo lsattr ./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D\:/workspace
-------------e-- ./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D:/workspace/directory2
user01@MyPC ~/somedirectory $ 

Come è stato montato il filesystem? Che tipo di file system è?
Raman Sailopal,

Tutto questo è sullo stesso filesystem ext4: il mio filesystem / home. È menzionato nel post
netikras il

2
Si prega di non pubblicare immagini di testo. E si prega di mostrare solo le informazioni pertinenti. Per lo meno, puoi rimuovere i comandi sbagliati! È molto difficile seguire il modo in cui lo stai mostrando.
terdon

devo modificare il post?
netikras,

2
Che dire della possibilità di un filesystem corrotto e della difficoltà a leggere gli inode? Dmesg segnala qualcosa?
Raman Sailopal,

Risposte:


17

Sui file basta leggere per verificare le autorizzazioni. È necessario leggere ed eseguire sulle cartelle per visualizzarle.

chmod -R a+X ./deploy_dir

Capital X da impostare viene eseguito solo su cartelle (e file che hanno già eseguito il set di bit).


5
Una volta ho trascorso mezza giornata su un problema simile, è facile perdere!
HoD

7

La lettura delle autorizzazioni di un file richiede la sua chiamata stat(2)e ciò richiede l'autorizzazione di esecuzione / accesso sulla directory di contenimento (tutte le directory nel percorso). Questo è in realtà lo stesso con ogni altra chiamata di sistema che accetta un nome file. Tuttavia, la lettura del contenuto di una directory (l'elenco dei nomi dei file) richiede solo l'accesso in lettura alla directory.

Nel tuo frammento di esempio:

~/somedirectory $ ls -l .../bin/D\:
ls: negaliu pasiekti '.../bin/D:/workspace': Permission denied
viso 0
d????????? ? ? ? ?            ? workspace

lsha provato a chiamare stat(".../bin/D:/workspace"), ha ricevuto un errore e si è lamentato. Su alcuni sistemi è possibile ottenere informazioni parziali dalle chiamate readdir/ getdentsinsieme ai nomi dei file, senza bisogno di usare stat. Come qui, workspaceviene mostrato come una directory.

E qui vediamo che non ci sono bit x per nessun utente:

~/somedirectory $ ls -ld .../bin/D\:
drw-r--r-- 3 user01 user01 4096 Rgs 27  2016 .../bin/D:

Come root, ottieni un elenco completo, poiché essendo root ignora completamente i bit di autorizzazione.


Potresti forse fare la stessa cosa, ma con l' LC_ALL=Cesportazione nel tuo ambiente?
un CVn del

1

Per guardare gli attributi dei file è necessario il diritto di leggere la directory. Se ciò non è possibile, verranno visualizzati i punti interrogativi.

Per il motivo per cui quell'utente non è in grado di leggere le informazioni, guarda gli attributi della directory ( .../D:/.sopra). Un'altra possibile causa potrebbe essere se la directory è stata rimossa o è inaccessibile (ad es. File system di rete, handle non aggiornato) per un motivo diverso rispetto alle modalità di accesso.


Aggiornato la domanda. Gli attributi sono tutti gli stessi di D: \, i suoi figli, la sua formica madre my ~ /. directory.
netikras,

E questa directory è lì da mesi ormai. Non sta scomparendo da nessuna parte. Sta chiaramente dicendo che, a meno che io non sia root, non posso entrare: / Ciò non funzionerebbe con i media o i filehandle che
sbattono,

Si prega di provare a controllare anche tutte le directory principali, se una di queste ha attributi che creano problemi (vedere se llfallisce come user01su qualsiasi genitore fino al root). Non c'è bisogno di pubblicare l'output, dicci solo il risultato per favore.
Ned64,

1
Ho appena tarato la directory, l'ho scappata su un altro server e ho fatto lo stesso lstest. Il risultato è identico
netikras il

2
Non hai la xbandiera, quindi HoD ha ragione. Non l'avevo visto nella tua produzione ingombra. stracete l'avrei detto. pure.
Ned64,

0

Oggi ho avuto un problema molto simile, con sintomi simili: punti interrogativi nei campi delle autorizzazioni e della proprietà, e anche con root / sudo non sono stato in grado di cambiare nulla di tutto ciò. Poi ho finalmente ricordato che questa particolare directory era in realtà il punto di montaggio di una directory sulla condivisione file di Windows, che avevo impostato poche settimane fa (in una sessione di prova per vedere se Samba / CIFS è utile per il mio progetto) e apparentemente nel frattempo è stato smontato. Dopo aver riemesso il mount.cifscomando e aver inserito le mie credenziali per la parte Windows della nostra rete, "ls" ha riportato le normali informazioni di autorizzazione e proprietà sulla directory. Dato che i sintomi erano esattamente come i tuoi, mi chiedo se ti trovi in ​​una situazione simile, anche perché "D:" sembra molto simile a Windows.


Salve, il segno di spunta verde indica che l'utente che ha posto la domanda ha contrassegnato la risposta come "accettata". Pertanto possiamo almeno supporre che le autorizzazioni siano state modificabili usando chmod. Questa directory si trova sotto la home directory degli utenti ( ~). Inoltre, sono già consapevoli che problemi come questo possono essere dovuti a problemi di montaggio con l'archiviazione remota.
sourcejedi,

Nota anche, il statcomando lo conferma. Confronta il Devicecampo per stat .vs sudo stat ./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D \: File: './deploy_dir/liferay-portal-6.1.1-ce -ga2 / tomcat-7.0.27 / bin / D: ' `. È lo stesso. Questo output è una buona prova del fatto che si trovano sullo stesso filesystem.
sourcejedi,

Ah giusto! Scusate il rumore ...
davino,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.