Quando copi un file su un diverso filesystem, quello che sta succedendo è che crei un nuovo file e ne copi il contenuto. Lo spostamento di un file in un file system diverso viene eseguito copiando e rimuovendo l'origine. Quindi non hai più privilegi quando copi un file che in qualsiasi altro momento in cui stai creando un file.

Quando crei un file, esso appartiene a te. Molte varianti unix limitano la modifica del proprietario ( chown ) a root. Anche quelli che consentono al proprietario di un file di darlo via cancellano i bit setuid e setgid quando lo fanno. Anche le modifiche alla proprietà del gruppo ( chgrp ) cancellano i bit di setxid a meno che non vengano invocati con i privilegi di root. E devi possedere il file o essere root per modificarne i permessi. Quindi non puoi creare un file setxid per un utente o gruppo per cui non hai il permesso di eseguire programmi.

Un vettore diverso per l'inserimento di file setxid è il montaggio del filesystem. La maggior parte delle configurazioni consente solo i bit setxid sui filesystem montati direttamente da root (al contrario delle voci / etc / fstab con l'opzione user su Linux, Samba, FUSE, ...). A volte, ad esempio con i montaggi NFS, spetta all'amministratore di sistema assicurarsi che i file system siano montati con l'opzione nosuid .

AGGIORNAMENTO: ignora la mia precedente risposta fuorviante, che ho modificato qui per evitare di confondere le persone. Gilles ha una risposta molto migliore, che potrei incorporare qui o riformulare, ma merita il merito ....

Se vuoi davvero vedere quello che ho avuto prima, puoi come sempre trovarlo nella modificare la cronologia facendo clic sull'ora della modifica.

Ti avvicini a questo comportamento quando scarichi il tarball di qualcuno e lo estrai, 'preservando la proprietà / permessi' se l'uid è 7544 vedrai quell'uid per i file che decomprimi se sei root, probabili errori se non sei utente privilegiato.