Steam non usa le sandbox. Ad esempio, in Windows, i giochi Steam di solito salvano i propri dati in Documenti, Appdata, nella propria cartella di installazione o nella cartella Steam Cloud di Steam (che si sincronizza con il servizio di archiviazione online per i salvataggi, le configurazioni e altri dati utente). Alcuni addirittura installano altri programmi, come la libreria di un componente multiplayer (ad es.:Giochi per Windows - LIVE).
Valve, tuttavia, ha messo in atto alcune restrizioni per prevenire comportamenti indesiderati, come un gioco che installa il mercato dei giochi di un editore senza chiedere. L'unica cosa più vicina a farlo è uPlay di Ubisoft, che Ubisoft voleva utilizzare per aggiornare i propri giochi, quindi invece di spedire il client completo ogni gioco viene fornito con una versione mini che manca del marketplace e può essere avviato solo quando avvii il gioco associato .
I giochi su Steam sono per lo più gli stessi delle loro controparti al dettaglio, solo leggermente modificati per utilizzare il DRM di autenticazione di Steam e resi scaricabili tramite i server di Steam.
Steam offre in cambio servizi aggiuntivi, come aggiornamenti automatici, sincronizzazione cloud dei dati utente del gioco, risultati, classifiche e altri dati personalizzati (guarda le statistiche di Team Fortress 2 di un utente per un esempio) e altro ancora.
Steam non protegge il tuo sistema da giochi non attendibili o da se stesso.
Potresti essere interessato all'articolo di Stéphane Graber sull'utilizzo di LXC per fare questo e al progetto steam-lxc che ha creato a tale scopo.
Aggiornamento di settembre 2014:
Finalmente sono riuscito a configurarlo da solo. I link qui sopra sono un po' obsoleti, ma Stéphane ha pubblicato una serie di articoli più recenti su LXC 1.0 che sono stati molto utili. Tra questi e un po' di sperimentazione, ho fatto funzionare Steam in un container non privilegiato, e funziona abbastanza bene.
Avviso: Anche se esegui Steam (e i suoi giochi) in un container, normalmente sarà comunque in grado di accedere allo schermo, al mouse e alla tastiera tramite il protocollo X. Esistono alcune estensioni X per mitigare questo problema, ma non ho ancora provato a eseguire Steam come client X non attendibile. Un modo semplice per limitare questa esposizione è creare un account utente Linux separato per il tuo contenitore Steam, utilizzare la funzione "cambia utente" del tuo ambiente desktop per accedere come quell'utente per giocare e passare da quella sessione desktop alla normale sessione desktop come necessario. Poiché questo approccio utilizza una sessione del server X separata per Steam, lo sniffing del protocollo X non dovrebbe essere possibile, anche se la GPU e i suoi driver potrebbero ancora essere sfruttabili sui server X.
La mia riga di comando per la creazione del contenitore:
lxc-create -n steambox -t download -- -d ubuntu -r trusty -a amd64
Ho modificato il mio file di configurazione del contenitore in modo che assomigli a questo:
# Distribution configuration
lxc.include = /usr/share/lxc/config/ubuntu.common.conf
lxc.include = /usr/share/lxc/config/ubuntu.userns.conf
lxc.arch = x86_64
# Container specific configuration
lxc.id_map = u 0 100000 1000
lxc.id_map = g 0 100000 1000
lxc.id_map = u 1000 1000 1
lxc.id_map = g 1000 1000 1
lxc.id_map = u 1001 101001 64535
lxc.id_map = g 1001 101001 64535
lxc.rootfs = /home/myusername/.local/share/lxc/steambox/rootfs
lxc.utsname = steambox
# Network
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = lxcbr0
lxc.network.hwaddr = 00:16:3e:77:88:99
# Video
lxc.mount.entry = /tmp/.X11-unix tmp/.X11-unix none bind,optional,create=dir
lxc.mount.entry = /dev/dri dev/dri none bind,optional,create=dir
lxc.mount.entry = /dev/nvidia0 dev/nvidia0 none bind,optional,create=file
lxc.mount.entry = /dev/nvidiactl dev/nvidiactl none bind,optional,create=file
#lxc.cgroup.devices.allow = c 195:* rwm
# video0 doesn't exist on my system.
#lxc.mount.entry = /dev/video0 dev/video0 none bind,optional,create=file
# Sound
lxc.mount.entry = /dev/snd dev/snd none bind,optional,create=dir
# Game Controllers
# Steam uses SDL for controller support; SDL uses udev and /dev/input/*
lxc.mount.entry = /dev/input dev/input none bind,optional,create=dir
#lxc.cgroup.devices.allow = c 13:* r
# uinput might be needed for gamepad support with streaming
#lxc.mount.entry = /dev/uinput dev/uinput none bind,optional,create=file
#lxc.cgroup.devices.allow = c 10:223 rwm
# for debugging
#lxc.aa_profile = unconfined
# EOF
Questo è pensato solo per iniziare. Dovrai comunque configurare il tuo sistema host come descritto negli articoli e probabilmente riavviarlo prima che funzioni. Per favore, non chiedermi di risolvere i problemi del tuo sistema.
Sto eseguendo Ubuntu con una scheda nVidia. Diverse distribuzioni e schede video probabilmente richiederanno percorsi, nomi di file e numeri di dispositivi diversi.
Nota che non ho impostato lxc.cgroup.devices.deny = a
tuttavia, quindi il contenitore non è così bloccato come potrebbe essere. (Lo cambierò una volta che avrò finito di sperimentare.)
Ho dovuto installare lo stesso pacchetto di driver nVidia nel contenitore che ho sull'host. (Anche una mancata corrispondenza del numero di versione minore ha causato errori quando Steam ha provato a utilizzare il driver.)
Ho usato deliberatamente l'architettura amd64 e la versione Ubuntu Trusty per il mio contenitore, nonostante Valve supporti solo i386 e Precise. L'ho fatto perché voglio che lo spyware di Valve mi annoveri tra coloro che utilizzano un sistema operativo moderno, nella speranza che inizino a supportarlo prima.
Una volta che Steam ha funzionato nel contenitore, ho impostato uno script di avvio sul mio sistema host. Si chiama steam
e vive nel mio PATH
, quindi le righe di comando di Steam funzionano praticamente come farebbero se Steam fosse installato normalmente. Ecco lo script:
#!/bin/sh
CONTAINER=steambox
RUNASUSER=ubuntu
STEAMCOMMAND=/usr/games/steam
# Execute a command in the container, with X display support
run_in_container() {
lxc-attach --clear-env -n $CONTAINER -- sudo -u $RUNASUSER -i \
env DISPLAY="$DISPLAY" "[email protected]"
}
# Find joystick devices so we can tell Steam's old SDL library to use them
# https://github.com/ValveSoftware/steam-for-linux/issues/1894#issuecomment-25295972
enum_joysticks() {
local joyprop=ID_INPUT_JOYSTICK=1
for f in /dev/input/*; do
if [ ! -c "$f" ]; then
continue
elif udevadm info --query=property --name="$f" | grep --quiet $joyprop; then
echo "$f"
fi
done
}
# Use the first arg as a separator to join the remaining args
join() {
local IFS="$1"
shift
echo "$*"
}
# Use an environment variable to help Steam's old SDL version find gamepads
run_steam_with_joysticks() {
run_in_container SDL_JOYSTICK_DEVICE="$(join : $(enum_joysticks))" \
$STEAMCOMMAND "[email protected]"
}
STARTED=false
if ! lxc-wait -n $CONTAINER -s RUNNING -t 0; then
lxc-start -n $CONTAINER -d
lxc-wait -n $CONTAINER -s RUNNING
STARTED=true
fi
run_in_container xauth add $(xauth list | sed 's/^.*\///')
run_steam_with_joysticks "[email protected]"
if [ "$STARTED" = "true" ]; then
lxc-stop -n $CONTAINER -t 10
fi
Il enum_joysticks
, join
e SDL_JOYSTICK_DEVICE=
le parti sono lì solo per aggirare un bug di Steam che impedisce alla modalità Big Picture di rilevare i controller di gioco su un sistema Ubuntu Trusty. Probabilmente potresti rimuovere quelle parti dallo script se il tuo contenitore esegue Ubuntu Precise o non utilizzi la modalità Big Picture.
Con quello script installato nel mio PATH
, posso copiare il file .desktop di ogni gioco dal mio contenitore al mio sistema host per far apparire il gioco nel menu delle mie applicazioni. (Di solito copio anche l'icona o modifico il file .desktop per assegnare un nome a un'icona installata sul mio host.)
cp /home/myusername/.local/share/lxc/steambox/rootfs/home/ubuntu/.local/share/applications/thegame.dekstop /home/myusername/.local/share/applications/
Buona fortuna!