Tutto e' possibile. Pero'... devi capire un po' di fondamenti di unix per fare sta roba in modo sensato.
E quell'os.system e' proprio poco incoraggiante.

Detto fra noi, per questo tipo di cose ti fai molto meno male ad usare bash. E' *veramente* scomodo scrivere questo tipo di script in Python.

Ma ripensandoci, perche' vuoi fare una cosa del genere? Quale e' il problema che ti interessa risolvere *davvero*?
Perche' a fare accrocchi con buchi grossi come delle case si fa presto e invece ci sono soluzioni standard e ben fatte per la maggior parte dei problemi.

Nello specifico, quale e' il tuo problema? Ovvero, non credo che tu "voglia cambiare utente con su prendendo la password memorizzata in una variabile".

Io credo che tu voglia... magari automatizzare qualcosa, magari hai degli script che ti chiedono venti volte la password e ti rompono le palle... Che ne so.

Quindi, capiamo il problema reale che hai e poi lo mettiamo a posto con gli strumenti opportuni.

Ok allora devo compilare un programma per ogni utente che creo, spostare il binario nella sua home cambiare il nome del binario con numero progressivo, del tipo programma1, programma2 ecc. poi devo loggarmi con l'utente creato per eseguire il programma e poi modificare il crontab dell'utente per lanciare il programma ad ogni riavvio.
I problemi che ancora non riesco a risolvere sono proprio il login e crontab, infatti ho provato sempre con os.system('crontab -e') ma non riesco a scrivere nel file in modo automatico.

Ah, sempre sta cosa. Avevo gia' ventilato i miei dubbi su tutto l'approccio. Tipo non mi e' chiaro che senso abbia compilare un programma per ogni utente e ficcarlo nella home invece che semplicemente intstallarlo per tutti e al limite mettere nella home solo uno scheletro della configurazione del programma. Perche' i programmi scritti in modo sensato non hanno bisogno del trattamento che descrivi. Cioe', immagino che ci sia qualche remoto edge case in cui la cosa ha senso, am a me proprio non viene in mente. Il che vuole dire che stai mettendo su una baracca molto complicata per nulla.

> P.S. io non sono un programmatore sto cercando di imparare python e per questo cerco di usare questo e non script in bash.

Si capisco. Pero' siamo sinceri... se usi Python come useresti bash, non impari Python. Impari a scrivere script di shell con una sintassi diversa.
Oh, poi fai come vuoi.

Posso capire le tue perplessità ma il programma che devo installare deve essere installato in questo modo, funziona così perciò chiedevo se era possibile fare quello che chiedevo, se è più semplice farlo in bash ti chiedo se potresti indicarmi qualche linea guida.

Dipende un po' da cosa hai a disposizione. Per dire questo qua funziona se il tuo sudo ha -S

[codice]
↑1 ~ → read -s PASSWORD && echo "$PASSWORD" | sudo -S whoami
Password:root
[/codice]

Si, ovviamente avevo disabilitato l'echo della password per cui subito dopo chi ha scritto l'output di whoami. Normalmente ci metto in mezzo un echo "
" per fare venire una roba tipo

Passowrd:
root

Comunque... se invece il tuo sudo non ha l'opzione -S, la faccenda diventa piu' fastidiosa. Parecchio. Beh, neanche tanto. Ho creato un interessante workaround. mer*a, mi sa che sto facendo troppe ops.

[codice]
↑1 ~ → read  -s BLAZ && SUDO_ASKPASS=blaz sudo whoami
root
Ξ ~ → cat blaz
echo "$BLAZ"
[/codice]

Scusa ma io devo eseguire un cambio utente quindi devo usare "su", comunque sono su Debian 8 sudo non lo uso con l'opzione "-s" ho provato il secondo script ma mi dice che a tutte e tre le righe comando non trovato.

Non mi e' chiaro perche' sei convinto di non potere usare sudo. Con sudo puoi lanciare *qualunque* comando come se fossi root (ok, se e' nei comandi ammessi, che tipicamente su un'installazione di default, se il tuo utente di partenza e' in wheel vuole dire *ogni* cosa. Se puoi diventare root, da li puoi fare quello che ti pare.

Scusa, e quindi quale e' il problema: la tua specifica non era corretta. A te non interessa lanciare su (perche' e' bello). A te interessa cambiare utente, e quindi hai pensato a su. Ma il fatto e' che ti interessa cambiare utente.

Detto questo saranno 10 anni che non uso su direttamente. Beh, forse 10 no. sudo e' generalmente considerato un'approccio piu' sicuro perche' piu' granulare (se vuoi; viceversa, puoi sarlo essenzialmente come replacement di su).

Scusa ma sudo da i privilegi di root temporanei ad un utente, non cambia utente, al massimo sudo su permette di cambiare utente, almeno io ho sempre fatto così, poi se con il solo sudo si cambia anche utente spiegami come fare e sarò ben lieto di farlo.

Sei molto confuso. Allora, prima di tutto il concetto di "essere un utente" non e' ben definito. Ovvero, in Unix quello che esiste e' che "un processo gira con un determinato utente". Fine. Unix non conosce altro. Ci sono utenti, ci sono processi che girano con un certo utente. Quindi cosa intendi con "sono un certo utente"? Intendi "ho una shell -- o altro prompt di comandi -- che gira con i permessi di quell'utente, per cui posso lanciare tutti i processi con i previlegi che ha quell'utente. Bene... per essere corti diciamo "sono" quell'utente. E' un buon modo abbrevviato di parlare.

Ok... quindi che cosa fa su?
"""
       su allows to run commands with a substitute user and group ID.

       When called without arguments, su defaults to running an interactive
       shell as root.
"""

Sudo invece..
"""
sudo allows a permitted user to execute a command as the superuser or another user, as specified by the security policy.
""""

Ora, ti sembra che ci sia differenza? Non e' che per evitare questo ping pong conviene che impari cosa fanno?

https://linux.die.net/man/8/sudo
http://man7.org/linux/man-pages/man1/su.1.html

1. "da root devo compilare un programma": no. E' una pessima idea. Scusa, "pessima" non inizia a descrivere il problema. Se il sistema non e' completamente rotto, da root non *devi* compilare nulla. Perche' per compilare ti basta essenzialmente avere i permessi per (1) i permessi di lettura sorgenti che devi compilare; (2) permessi di scrittura (e possibilmente lettura ed exec) si una qualche sottodirectory da qualche parte nel filesystem [ammesso che il programma da compilare non sia stato scritto da persone prive dei pollici opponibili, nel qual caso potresti avere bisogno dei permessi per scrivere nella stessa directory dove stanno i sorgenti -- cosa che puoi comunque ovviare copiando i sorgenti nella singola directory dove hai i permessi di scrittura). Questo e' completamente sufficiente per "compilare" un programma. Ah, ovviamente devi anche (3) avere permesso di esecuzione sui programmi che usi per compilare (che e' piuttosto default in una qualunque installazione Unix sensata -- al piu' non ci sono installati i tools, ma quello e' un problema diverso --). Piu' (4) permessi di lettura per alcune cose quali le librerie contro cui devi linkare e gli header di suddette librerie (se il linguaggio in questione ha il contesto di header). Davvero, compilare da root e' una nota bad practice e troverai quintali di informazioni nel web sul perche'.

2. Ti e' chiaro che in Unix, una volta che sei root puoi fare quello che ti pare (salvo poche operazioni sull'hardware per le quali non basta essere root ma devi essere il kernel e due o tre cose che non puo' fare nessuno -- se non il kernel -- per ottimi motivi tecnici)? Dal che discende che una volta che puoi diventare root (ovvero, aprire una shell che gira con i permessi di root) puoi fare proprio tutto quello che vuoi, incluso lanciare comandi con i permessi di un altro utente? Quindi, se puoi diventare root puoi:

a. creare gli utenti che ti pare, con la loro home e la loro password
b. compilare il programma suddetto proprio come root (anche se e' una pessima idea farlo); o meglio... compilarlo come utente non previlegiato
c. spostare file da ovunque a dove ti pare (ok, a patto che il medium su cui scrivi sia scrivibile)... specificamente  puoi spostare nella home di chi ti pare il file che ti pare (e non solo: puoi anche attribuirgli l'ownership dell'utente e del gruppo che piu' ti aggrada: hei, puoi anche fare combinazioni in cui nessun utente che non sia root puo' di fatto accedere al file! cooll!)
d. lanciare un qualunque programma con i permessi di qualunque utente (specificamente "loggarti" vuole eseguire /bin/login o al limite una shell: quindi si, puoi loggarti come chi ti pare) e lanciare il programma (o anche direttamente lanciare il programma con suddetti permessi -- senza fare login!)

Insomma... una volta che sai come diventare root, puoi fare grosso modo quello che ti pare su un sistema. Anche le cose che non dovresti fare.

E personalmente quello che vuoi fare non dovresti farlo perche' ci sono due casi:
1. il programma di cui parliamo e' veramente scritto in modo demenziale (e si, ce ne sono)
2. non hai la minima idea di quello che stai facendo e ti stai inventando requisiti immaginari
3. chi sta sopra di te dovrebbe cambiare mestiere e smetterla di darti processi privi di senso da implementare (nel quale caso mi dispiace tantissimo per te: avere capi idioti e' decisamente un incubo)

Ora, io il programma non lo conosco e non ti so dire... pero' *davvero* devo essere io a spiegarti che:

"""
esempio da root creo l'user Pippo compilo il programma, lo sposto nella home con nome "programma_Pippo" quindi do un " su Pippo" inserisco la password di Pippo e mi ritrovo nella shell loggato come Pippo mi sposto nella home con "cd /home/Pippo" e lancio il programma con "./programma_Pippo".
""""

e' banale una volta che sai essere root? E *davvero* devo spiegarti io come funziona sudo? sudo e' venuto fuori nel 1980 (36 anni fa) ed e' uno strumento di default dell'amministrazione dei sistemi da *tanto* tempo. E in OS X, ma soprattutto un po' di distribuzioni Linux di quelle "critiche", e' lo strumento di default, tanto che root in quanto root non e' manco abilitato come utente per fare login. Sinceramente non ricordo l'ultima volta che ho fatto su invece di sudo (anche perche' tipicamente se hai un briciolo di attenzione alla sicurezza non vuoi che la gente faccia su, ma puoi rendere sensato fare sudo).

Poi, gia' che ci siamo... tutta questa idea di installare nella home di *ogni* utente il "maggico programma" e' proprio un'idea nata male. Spero solo che il programma sia stato scritto da gente senza pollici opponibili e che tu ci sia costretto. Perche' nella norma i programmi si installano in directory condivise e poi gli utenti lanciano il programma (che, guarda caso, avrai i permessi di chi lo esegue -- ovviamente chi esegue deve avere i permessi per eseguire --. Uff.. mi sembra fuori luogo qui entrare nei dettagli delle differenze fra uid, euid e, per i sistemi che lo implementano, fsuid. Giusto per rendere meno che demenziale aggiornare -- specie se sei fuori dalla casa delle bambole ed esistono piu' di "una macchina" su cui hai le home di "tutti gli utenti" --.