chown rimuove il bit setuid: bug o funzionalità?

14

I passaggi per riprodurre:

germar@host:~$ cd /tmp/
germar@host:/tmp$ touch test && chmod u+s test && ls -la test
-rwSr--r-- 1 germar germar 0 Nov  2 20:11 test
germar@host:/tmp$ chown germar:germar test && ls -la test
-rw-r--r-- 1 germar germar 0 Nov  2 20:11 test

Testato con Debian Squeeze e Ubuntu 12.04

permissions users chown

— Germar
fonte

Lo fa anche su Fedora 17.

— BenjiWiebe,

1

caratteristica

— mikeserv

17

Non un bug secondo la documentazione di Chown:

$ info coreutils 'chown invocation'

   The `chown' command sometimes clears the set-user-ID or set-group-ID
permission bits.  This behavior depends on the policy and functionality
of the underlying `chown' system call, which may make system-dependent
file mode modifications outside the control of the `chown' command.
For example, the `chown' command might not affect those bits when
invoked by a user with appropriate privileges, or when the bits signify
some function other than executable permission (e.g., mandatory
locking).  When in doubt, check the underlying system behavior.

— jlliagre
fonte

Grazie Jlliagre. Non lo sapevo info coreutilsprima Ho letto solo la man-page e cercato nel web.

— Germar,

12

Questo è di progettazione ed è un comportamento standard. Citando lo standard POSIX :

A meno che chown non sia invocato da un processo con i privilegi appropriati, i bit set-user-ID e set-group-ID di un file normale devono essere cancellati al completamento con esito positivo; i bit set-user-ID e set-group-ID di altri tipi di file possono essere cancellati.

( sè setuid (o setgid nella colonna del gruppo), non appiccicoso, comunque).

Questo comportamento segue quello della chiamata di sistema sottostante (tranne che su alcuni sistemi, i bit setxid vengono cancellati solo per i file eseguibili).

Il motivo della rimozione del bit setuid è che cambiando il proprietario cambia anche quale utente sarà l'ID utente effettivo del processo. In particolare, sui sistemi in cui un utente può regalare un file, cp /bin/sh foo; chmod u+s foo; chown joe foocreerebbe un eseguibile setuid appartenente a joe, una gigantesca falla di sicurezza.

— Gilles 'SO- smetti di essere malvagio'
fonte

Upoting per il nitpick! SUID / SGID non sono un po '"appiccicosi"!

— Jim Dennis,

Ottimo punto sulle implicazioni di sicurezza della conservazione di SUID / SGID. Sono stato infastidito dal comportamento fino a quando ho letto quella frase. Aggiungerei, tuttavia, non ho mai visto Chown non cancellare i bit, anche quando si esegue come root. Sono curioso di sapere quali "privilegi appropriati" implicherebbero.

— vastlysuperiorman,

1

@vastlysuperiorman Su una piattaforma Unix classica, "privilegi appropriati" significa ID utente 0. Ma POSIX consente ai sistemi di definire le proprie politiche di sicurezza. Ad esempio, per molte operazioni su Linux, i "privilegi appropriati" sono implementati come funzionalità (che solo root ottiene per impostazione predefinita). In questo caso particolare, sopprime i bit setxid su chown indipendentemente dai privilegi, come la maggior parte se non tutte le varianti Unix. Ma un livello POSIX su Windows potrebbe funzionare in modo diverso.

— Gilles 'SO- smetti di essere malvagio' il