# Scusate ma non ho capito nulla sui permessi finora [RISOLTO]

## Cazzantonio

```
freevo@heremitpurple ~ $ ll /home/data/

total 20K

drwxrwx---  3 freevo users freevo 4.0K 2007-11-30 10:49 LOCALE

drwxrwx---  2 freevo users freevo 4.0K 2007-11-28 18:34 RETE

-rw-r--r--  1 root   root  root    813 2007-12-02 19:13 freevo_fs_op.fxd

freevo@heremitpurple ~ $ mv /home/data/freevo_fs_op.fxd .

freevo@heremitpurple ~ $ 

```

WTF!!!   :Shocked:   :Shocked: 

Si è proprio così:

```
freevo@heremitpurple ~ $ ll freevo_fs_op.fxd 

-rw-r--r-- 1 freevo users freevo 813 2007-12-02 19:13 freevo_fs_op.fxd

freevo@heremitpurple ~ $ mv freevo_fs_op.fxd /home/data/

freevo@heremitpurple ~ $ ll /home/data/

total 20K

drwxrwx---  3 freevo users freevo 4.0K 2007-11-30 10:49 LOCALE

drwxrwx---  2 freevo users freevo 4.0K 2007-11-28 18:34 RETE

-rw-r--r--  1 freevo users freevo  813 2007-12-02 19:13 freevo_fs_op.fxd

freevo@heremitpurple ~ $ 

```

L'utente freevo ha rimosso un file di proprietà di root da una cartella e lo ha copiato nella propria, con il risultato che ora è addirittura cambiato il prorietario!

Cosa accidenti sta succedendo???

Ditemi che è una stronzata e sono rimbecillito io please! Da quando in qua è possibile fare una cosa del genere??

Siccome questa cosa per me incomprensibile la fa su due macchine diverse significa che sono veramente ignorante io? Finora ho completamente ignorato come funzionassero i permessi su linux? Accetto qualsiasi risposta, mi basta capire...

----------

## .:deadhead:.

Questo è quanto accade sulla mia macchina:

```
deadhead@stakanov ~/video $ ls -lsah

totale 12M

   0 drwxr-xr-x  3 deadhead users  110 29 nov 12:05 ./

8,0K drwxr-xr-x 68 deadhead users 4,0K  2 dic 20:38 ../

1,0K -rw-rw-rw-  1 deadhead users   24  5 ott 12:45 .directory

   0 drwxr-xr-x  2 deadhead users   19 27 nov 14:26 dvdauthor/

1,0K -rw-r--r--  1 deadhead users  155 27 nov 16:49 dvdauthor.txt

 11M -rw-r--r--  1 root     root   11M 17 apr  2007 wallstrip.flv

deadhead@stakanov ~/video $ mv -i wallstrip.flv .

mv: `wallstrip.flv' e `./wallstrip.flv' sono lo stesso file
```

opzioni di mount?

che fs?

che permessi ha la cartella ~ ?

----------

## lucapost

alias strani nel ~/.bashrc, magari inseme a sudo?

----------

## mambro

Mmmm, succede anche a me..

```

mambro@marte ~/permessi $ su

Parola d'ordine:

marte permessi # echo "ciao" > file

marte permessi # ls -l

totale 4

-rw-r--r-- 1 root root 5  2 dic 21:58 file

marte permessi # exit

exit

mambro@marte ~/permessi $ ls -l

totale 4

-rw-r--r-- 1 root root 5  2 dic 21:58 file

mambro@marte ~/permessi $ rm file 

rm: rimuovere il regular file protetto dalla scrittura `file'? y

mambro@marte ~/permessi $ ls -l

totale 0

```

 :Shocked: 

Il mio bashrc sembra pulito, sudo ce l'ho installato per via di libgksu ma in /etc/sudo ho solo:

```

Defaults        env_reset

root    ALL=(ALL) ALL

```

----------

## flocchini

```
flocchini@sovereign ~ $ mkdir permessi

flocchini@sovereign ~ $ cd permessi

flocchini@sovereign ~/permessi $ su

Password:

sovereign permessi # echo "ciao" > file

sovereign permessi # ls -l

total 4

-rw-r--r-- 1 root root 5 Dec  3 00:40 file

sovereign permessi # exit

exit

flocchini@sovereign ~/permessi $ ls -l

total 4

-rw-r--r-- 1 root root 5 Dec  3 00:40 file

flocchini@sovereign ~/permessi $ rm file

rm: remove write-protected regular file `file'? y

flocchini@sovereign ~/permessi $ ls -l

total 0

flocchini@sovereign ~/permessi $
```

differente rispetto a 

```
flocchini@sovereign ~ $ su

Password:

sovereign flocchini # mkdir permessi

sovereign flocchini # cd permessi

sovereign permessi # echo "ciao" > file

sovereign permessi # ls -l

total 4

-rw-r--r-- 1 root root 5 Dec  3 00:43 file

sovereign permessi # exit

exit

flocchini@sovereign ~ $ cd permessi/

flocchini@sovereign ~/permessi $ rm file

rm: remove write-protected regular file `file'? y

rm: cannot remove `file': Permission denied

flocchini@sovereign ~/permessi $           
```

----------

## HoX

 :Shocked:  Pure a me permette di cancellare il file creato da root... ma solo se sono nella cartella ~ e sottocartelle. Nelle altre cartelle non me lo permette... direi quindi che considera i permessi sulla cartella e non quelli del file...

----------

## koma

 :Shocked: 

Avete causato un cosa di stato qui in azienda.

----------

## Kernel78

Sembra proprio che prenda i permessi della cartella ...

se si crea una cartella in /tmp come utente normale i file di root che ci vengono creati possono essere cancellati o modificati dal proprietario della cartella.

----------

## Cazzantonio

Ed è normale che prenda i permessi della cartella?   :Shocked: 

Io vi giuro! Non l'ho mai nemmeno immaginato! Probabilmente è una cosa nota e stranota... prima di fare questo post mi sono vergognato alquanto interiormente... E' davvero il comportamento normale di linux? I permessi dei file non contano, contano solo quelli delle cartelle?

In questo momento mi sento un misto di vergognosa ignoranza e innocente stupore... tutto questo tempo passato su linux e non mi sono mai accorto di una cosa del genere??

P.S. lo fa anche con le directory! Una sottodirectory creata da root in una directory di proprietà di un utente può essere rimossa dall'utente! (e anche spostata, rinominata, etc...).

Io basisco... non ho parole...

----------

## cloc3

 *Cazzantonio wrote:*   

> Ed è normale che prenda i permessi della cartella?  
> 
> 

 

non sono sicuro che sia necessariamente così e non sono sicuro che sia sempre stato così. nel senso che, probabilmente, la gestione dei permessi, su questo punto può dipendere può essere interpretata dal software che prende la decisione (il driver del file system?).

in ogni caso, l'interpretazione attuale è coerente con il concetto di permesso: l'utente ha il permesso di scrivere nella cartella? ebbene, scrivere nelle cartella significa esattamente aggiungere, togliere file e modificare i permessi.

questo può avere anche dei vantaggi. per esempio, nessun utente semplice può rimuovere la propria cartella personale, proprio perché è contenuta in una cartella protetta.

----------

## morellik

Sembra invece sia normale. Un utente proprietario di una directory può rimuovere tutti i file al suo interno siano essi

suoi o di qualcun altro. Se non si vuole questo comportamento occorre operare come per la directory /tmp.

Ecco alcuni commenti di altri amministratori di sistemi Linux:

the directory permissions determine whether a file can be deleted - not the file permissions. 

To delete files you need write permissions for the directory they're in.

File permissions themselves are irrelevant here. If there are other users using that directory, consider using the same

approuch on that directory that's traditionally used on /tmp - i.e., 

set the directory 'sticky' bit.

----------

## .:deadhead:.

Allora, se la dir in cui root ha scritto è dell'utente pippo è normale che pippo possa cancellare il file.

La dir alla fine non è altro che un lungo elengo di puntatori a files. Chiarito questo appare "normale" come un utente possa cancellare un file di root: pippo può scrivere nel "file-cartella" e può quindi eliminare la riga relativa al puntatore al file, cancellando alla fine della fiera, il file.

Il problema esposto da Cazzantonio mi sembra diverso perchè lui muove un file su sè stesso e il sistema glielo fà fare... Come avete visto a me dà l'errore che i files sono uguali e non ci si mette neanche.

Anche perchè un conto è eliminare un file su cui si ha il potere, un altro è cambiare il proprietario del file, operazione che è sì appannaggio SOLO di root!

----------

## gutter

 *Cazzantonio wrote:*   

> Ed è normale che prenda i permessi della cartella?  
> 
> 

 

Una breve spiegazione. Qualcuno una volta disse:

 *Quote:*   

> In Unix all is a file.

 

partendo da quest'asserto, considera per un momento una directory come un file e tutto sarà più chiaro.

Le entry di una directory non sono altro che dei riferimenti a file, quindi se la directory ti appartiene (a livello di permessi) non vedo perché tu non possa modificarla indipendentemente da chi è il proprietario della entry (il file) che modifichi.

Spero di essermi spiegato.

----------

## Cazzantonio

Bene, scusatemi infinitamente ma davvero in tutti questi anni non mi era mai sorto il sospetto che un utente potesse cancellare un file creato da root!   :Embarassed: 

Posto una pezza a questa mia incredibile manchevolezza vorrei tranquillizzare .:deadhead:.

Se puoi leggere e rimuovere un file puoi farne una copia e metterla al posto dell'originale con il proprietario cambiato. è assolutamente normale.

----------

## djinnZ

@morellik:

è normale quello che dici tu (non capisco il problema davvero) quindi se ho un file o una directory di proprietà di root posso spostarlo/cancellarlo etc. anche se non ho i permessi di scrittura/lettura/esecuzione su di esso. Fin qui ci siamo.

Ma non posso appropriarmi dell'ownership di un file anche se è in una directory di mia proprietà.

la cosa anomala di quel che ha riportato cazzantonio è il cambio di owner che senza acl/sticky bit non è possibile a quel che ne so io.

@cazzantonio:

sono su hardened ed ovviamente con acl quindi avrebbe poco senso ma ho verificato e non funziona così. In ogni caso il comportamento di mv è anomalo.

verifica meglio con un file su cui non hai permesso di lettura perchè se è così è un buco grosso quanto un palazzo e sarebbe il caso di aprire immediatamente un bug

tanto per curiosità verifica sulla stessa macchina se dovesse funzionare un chown user file_di_root dalla shell dell'utente. Se è così mi sa che ti hanno pasticciato la macchina.

----------

## randomaze

 *djinnZ wrote:*   

> la cosa anomala di quel che ha riportato cazzantonio è il cambio di owner che senza acl/sticky bit non è possibile a quel che ne so io.

 

No, perché c'era il permesso in lettura del file. La move si é comportata come se fosse "cp+rm".

----------

## djinnZ

 *randomaze wrote:*   

> No, perché c'era il permesso in lettura del file. La move si é comportata come se fosse "cp+rm".

 

e non deve funzionare così. Move non è la stessa cosa di "cp vecchio nuovo ; rm nuovo". Per me è un bug.

----------

## morellik

A me non succede (XFS):

```

[mia_home] ls -la test

-rw-r--r-- 1 root root 5 Dec  3 11:37 test

[mia_home]  mkdir pippo

[mia_home] mv test pippo

[mia_home] ls -la pippo

total 20

drwxr-xr-x   2 morelli users    17 Dec  3 11:38 .

drwxr-xr-x 162 morelli users 12288 Dec  3 11:38 ..

-rw-r--r--   1 root    root      5 Dec  3 11:37 test

```

----------

## djinnZ

Non ci avevo pensato, potrebbe essere colpa del filesystem. Faccio un paio di prove.

@cazzantonio: ma che cavolo di filesystem usi? ufat?  :Laughing: 

----------

## table

Mi pare di ricordare che con selinux non si deve mai confondere un mv con un cp.

Avevo seguito un breve seminario a proposito di sta cosa ma non mi ricordo bene i dettagli.

In ogni caso ecco cosa succede sulla mia gentoo con fs EXT3:

```

table@localhost ~ $ su

Password:

localhost table # echo "ciao" > file

localhost table # ls -l

-rw-r--r--  1 root  root        5 Dec  3 12:50 file

localhost table # exit

exit

table@localhost ~ $ ls -l

-rw-r--r--  1 root  root        5 Dec  3 12:50 file

table@localhost ~ $ rm file

rm: remove write-protected regular file `file'? y

table@localhost ~ $ ls -l

total 0 
```

 :Laughing:   :Laughing:   :Laughing:   :Laughing:   :Shocked:   :Shocked:   :Shocked:   :Shocked:   :Shocked: 

E qui invece:

```
table@localhost ~ $ su

Password:

localhost table # mkdir permessi

localhost table # cd permessi/

localhost permessi # echo "ciao" > file

localhost permessi # ls -l

total 4

-rw-r--r-- 1 root root 5 Dec  3 12:55 file

localhost permessi # exit

exit

table@localhost ~ $ cd permessi/

table@localhost ~/permessi $ rm file

rm: remove write-protected regular file `file'? y

rm: cannot remove `file': Permission denied

table@localhost ~/permessi $   
```

 :Shocked:   :Shocked:   :Shocked:   :Sad:   :Wink:   :Rolling Eyes:   :Very Happy: 

----------

## mambro

Effettivamente a me mv non cambia i permessi del file.

```

mambro@marte ~ $ cd permessi/

mambro@marte ~/permessi $ su

Parola d'ordine:

marte permessi # echo "ciao" > blabla

marte permessi # ls -l

totale 4

-rw-r--r-- 1 root root 5  3 dic 18:03 blabla

marte permessi # exit

exit

mambro@marte ~/permessi $ mv blabla mioblabla

mambro@marte ~/permessi $ ls -l

totale 4

-rw-r--r-- 1 root root 5  3 dic 18:03 mioblabla

mambro@marte ~/permessi $ rm mioblabla 

rm: rimuovere il regular file protetto dalla scrittura `mioblabla'? y

mambro@marte ~/permessi $ ls -l

totale 0

```

La home è montata così:

```

/dev/sda5               /home           ext3            defaults        0 0

```

----------

## djinnZ

ok ho verificato che su hardened reiser ext e xfs sono coerenti quindi mv!=cp+rm.

@mambro: questo è il comportamento normale. Se procedevi con cp invece ti dovevi ritrovare mambro invece di root come owner (anche se non è una bella cosa ma aveva una sua ragione).

@table Non è solo in selinux ma in tutti i sistemi posix che cp e mv corrispondono a due funzioni diverse.

Ho specificato che uso hardened perchè il profilo implica le patch per il supporto alle acl e differenti versioni di libc e baseutils rispetto al profilo standard.

----------

## mambro

 *djinnZ wrote:*   

> 
> 
> @mambro: questo è il comportamento normale. Se procedevi con cp invece ti dovevi ritrovare mambro invece di root come owner (anche se non è una bella cosa ma aveva una sua ragione).
> 
> 

 

Si, funziona così. Ma a Cazzantonio no   :Very Happy: 

Io non uso un profilo hardened nè tantomeno selinux e acl. Quindi è confermato che mv è diverso da cp+rm anche nei sistemi "default".

----------

## Cazzantonio

 *djinnZ wrote:*   

> @cazzantonio: ma che cavolo di filesystem usi? ufat? 

 ext3...

Comunque a me mv, se invocato da utente, cambia i permessi. Si comporta esattamente come cp+rm

----------

## djinnZ

quindi il tuo sistema è bacato e devi aggiornarlo.

Sto tirando ad indovinare ma in questo caso sia cp che mv molto intelligentemente dovrebbero, se usati su device&C, invece di farne una copia o bloccarsi dovrebbero copiarne il contenuto sulla destinazione, con il risultato di far schiantare il sistema, in particolare al primo aggiornamento di baselayout, udev o non ricordo che altro.

Lo so perchè ci ho messo un discreto quantitativo di bestemmie prima di capire perchè mi si freezava il sistema ogni volta che tentavo di aggiornare.

Ma nel mio caso era determinato dalle patch per il supporto alle acl

----------

## mack1

Beh non vorrei fare figuracce ma siccome chi non chiede non impare mai niente:

la mia home è su una partizione separata e montata con noexec:

```

xxxGen ~ # mount | grep /home

/dev/sda7 on /home type ext3 (rw,noexec,nosuid,nodev,noatime,nodiratime)

```

Ho installato wine e poi emule che risiede all'interno della partizione home:

```

merlinuxxx@xxxGen ~ $ ls -a ~/

.              .bashrc                Desktop      .fonts.conf    .kde3.5         .macromedia          .recently-used.xbel  .wine

..             CCNA-3.1.1             .dmrc        .gkrellm2      .kderc          .mplayer             software             .Xauthority

.bash_history  .config                doc-pdf      .gnupg         .kinorc         music                .thumbnails          .xsession-errors

.bash_logout   .DCOPserver_xxxGen__0  .fontconfig  .ICEauthority  .ktorrent.lock  .nvidia-settings-rc  torrent

.bash_profile  .DCOPserver_xxxGen_:0  .fonts       .kde           .local          .qt                  .tvtime

merlinuxxx@xxxGen ~ $ ls -a ~/ | grep wine

.wine

merlinuxxx@xxxGen ~ $ ls -a .wine

.  ..  dosdevices  drive_c  system.reg  userdef.reg  user.reg

merlinuxxx@xxxGen ~ $ ls -a .wine/drive_c

.  ..  Programmi  windows

merlinuxxx@xxxGen ~ $ ls -a .wine/drive_c/programmi

ls: impossibile accedere a .wine/drive_c/programmi: No such file or directory

merlinuxxx@xxxGen ~ $ ls -a .wine/drive_c/Programmi

.  ..  Common Files  eMule  Internet Explorer

merlinuxxx@xxxGen ~ $ ls -a .wine/drive_c/Programmi/eMule

.                  changelog.txt  downloads.txt  eMule Light.tmpl  lang             LinkCreator.exe  Temp                    Uninstall.exe

..                 config         eMule.chm      eMule.tmpl        license-GER.txt  readme.txt       Template.eMuleSkin.ini  webserver

changelog.ger.txt  downloads.bak  emule.exe      Incoming          license.txt      skins            Template.Notifier.ini

merlinuxxx@xxxGen ~ $ ls -l .wine/drive_c/Programmi/eMule/emule.exe

-rwx------ 1 merlinuxxx merlinuxxx 5308416 13 mag  2007 .wine/drive_c/Programmi/eMule/emule.exe

```

Il bello è che posso eseguire emule anche se si trova dentro la mia partizione  :Evil or Very Mad: 

```

merlinuxxx@xxxGen ~ $ wine .wine/drive_c/Programmi/eMule/emule.exe

WARNING: Trying to create a socket of type SOCK_RAW, this will fail unless you have special permissions.

WARNING: Trying to use ICMP (network ping) will fail unless running as root

err:listview:LISTVIEW_WindowProc unknown msg 108a wp=00000000 lp=0033d860

....etc

merlinuxxx@xxxGen ~ $ ps u

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND

1000      6422  0.0  0.0   4160  1716 pts/1    Ss   22:34   0:00 /bin/bash

1000      6885  9.0  1.3 2672892 27188 pts/1   SLl+ 22:45   0:07 .wine/drive_c/Programmi/eMule/emule.exe

1000      6925  0.0  0.0   4160  1704 pts/2    Ss   22:46   0:00 /bin/bash

1000      6944  0.0  0.0   2504   984 pts/2    R+   22:47   0:00 ps u

```

Come è possibile se la mia home è montata con l'opzione noexec???

Ciao

----------

## codadilupo

suppongo sia perchè tu non esegui emule, ma wine, che non mi pare si trovi sulla tua home

Coda

----------

## mack1

@codadilupo

Ok, ma non sembra un modo per saltare a piedi pari l'opzione noexec impostata sulla mia home, con tutte le conseguenze del caso?

Ciao

----------

## djinnZ

il permesso di esecuzione è una cosa che appartiene al mondo *nix non quello M$.

Wine si comporta come rundll32 quindi di suo esegue tutto quello che è eseguibile secvondo estensione del nome o intestazione del file (uno dei tanti motivi per cui winzozz è un colabrodo). Il kernel ed il vfs vedono solo una instanza di wine non amule in esecuzione. Come dire che avvi un editor su un file, il kernel al massimo può verificare se l'istanza ha il permesso di leggerlo quel file non  ha certo idea che vengono eseguite delle istruzioni in base ad esso.

Se però provi ad eseguire un binario linux esterno (tipo usare la jre/copia di firefox di linux invece di quella winzozz) quello dovrebbe essere eseguito o meno secondo i permessi.

Per lo stesso motivo se fai uno script "fesso.sh" contenente un bel 

```
rm -Rf * *
```

, lo metti nella home montata con noexec (o non ha attibuto di esecuzione, fa lo stesso) e scrivi 

```
. fesso.sh
```

 te lo esegue ugualmente.

Un mezzo workaround per evitare errori stupidi del tipo "wine suoneriegratisdellamaremmamaiala.exe" è impostare l'esecuzione automatica del codice windozz attraverso il supporto ai misc binaries del kernel ma la cosa ha delle ulteriori implicazioni di (in)sicurezza.

----------

## codadilupo

trovo complicato per noexec capire che deve bloccare l'esecuzione da parte di un software che non sta in home, di un exesguibile compilato per un altra architettura, per cui - suppongo - sia un comportamento normale, ma attendo smentite o conferme  :Wink: 

Coda

----------

## mack1

@djinnZ

Mi sembra la spiegazione migliore:in pratica wine essendo esterno alla partizione, quando manda in esecuzione quellochevuoi .exe, il kernel (e vfs) "vede" .exe come se fosse ,per esempio, un file di testo che viene semplicemente letto e non mandato in escuzione da wine !Ecco come aggira no exec  :Cool: .

@codadilupo

La mia era solo una curiosità, visto poi che si parlava di permessi...

Ciao e grazie

----------

## djinnZ

 *mack1 wrote:*   

> !Ecco come aggira no exec 

 

e ridagli! Non aggira nulla.

Semplicemente funziona in maniera differente perchè sono nati con due concezioni diverse. La stessa cosa capita con java, con i .net, e con qualsiasi cosa venga interpretata.

In realtà l'unico modo per risolvere il problema è usare un utente dedicato ed una policy di sicurezza adeguata altrimenti il rimedio potrebbe essere peggiore del male.

----------

## mack1

@djinnZ

Ok era quello che più o meno cercavo di dire   :Embarassed:  ....noexec >>>eseguibili *nix su quello che non è *nix non può fugere!!!

grazie della risposta  :Very Happy: 

Ciao

----------

## Jisaw

 *randomaze wrote:*   

>  *djinnZ wrote:*   la cosa anomala di quel che ha riportato cazzantonio è il cambio di owner che senza acl/sticky bit non è possibile a quel che ne so io. 
> 
> No, perché c'era il permesso in lettura del file. La move si é comportata come se fosse "cp+rm".

 

Mi pare di ricordare che dipenda da dove effettui la mv. Se effettui la mv in un ramo della stessa partizione in cui sei non viene creato nessun file, viene solo cancellato e ricreato un puntatore ad un inode già presente, a patto di avere i permessi di scrittura sulla directory (si può provare aggiungendo l' opzione i di ls, che mostra il numero di inode, rimane lo stesso). Se invece si fa la mv in un altro disco oppure un' altra partizione allora mv si comporta come una cp+rm, perchè gli inode non sono condivisi tra diverse partizioni. L' inode, infatti, risulta diverso. In questo caso sulla mia macchina, con fs ext3, se muovo un file non di mia proprietà nella mia home viene creata una copia del file con i permessi del mio utente e cancellato il file dalla posizione originale, se il mio utente ha il permesso di scrittura su quella directory.

----------

## cloc3

 *Cazzantonio wrote:*   

> Accetto qualsiasi risposta, mi basta capire...

 

oggi stavo leggendo alcuni brani delle specifiche UNIX, scaricate direttamente da http://www.opengroup.org e mi sono ricordato di questo topic.

il fatto di leggere e modificare il contenuto di /home/data scende semplicemente dal fatto che tu hai i permessi sulla cartella:

 *Quote:*   

> 
> 
> 4. General concepts
> 
> ...
> ...

 

una sola delle condizioni previste è sufficiente, nel tuo caso la seconda.

il fatto di cambiare il proprietario è previsto in caso di necessità:

 *Quote:*   

> 
> 
> NAME
> 
> mv - move files
> ...

 

dunque: cp+rm, come si diceva sopra.

----------

## CarloJekko

bisogna inserire o sticky bit nella directory

```
Sticky bit on a directory allows only the owner of a file (and to superuser) to delete it.

```

----------

