(Copiado da minha resposta aqui , desde que eu vi isso primeiro, e não parece certo marcar isso como uma duplicata de uma pergunta feita depois.)
As sessões de convidados são bloqueadas usando o AppArmor, que usa uma longa lista de permissões especiais para impedir que usuários convidados toquem em algo. Estes são acessados a partir de etc/apparmor.d/lightdm-guest-session
.
Na minha máquina, esse arquivo é assim:
# Profile for restricting lightdm guest session
#include <tunables/global>
/usr/lib/lightdm/lightdm-guest-session {
# Most applications are confined via the main abstraction
#include <abstractions/lightdm>
# chromium-browser needs special confinement due to its sandboxing
#include <abstractions/lightdm_chromium-browser>
}
Abrindo essa "abstração principal" ( etc/apparmor.d/abstractions/lightdm
) dá algo mais interessante:
...
/ r,
/bin/ rmix,
/bin/fusermount Px,
/bin/** rmix,
/cdrom/ rmix,
/cdrom/** rmix,
/dev/ r,
/dev/** rmw, # audio devices etc.
owner /dev/shm/** rmw,
/etc/ r,
/etc/** rmk,
...
Estes são todos os diretórios que uma sessão restrita pode acessar, junto com suas permissões. Se você adicionar sua partição e pasta compartilhada a essa lista (com% de /**
para incluir todos os subdiretórios e r
para permissão de leitura), todas as futuras sessões de convidados terão acesso somente leitura a ela.
Para permissões de leitura e gravação, use rw
; essa é a permissão padrão para /var/guest-data
. Para permissões completas, use rwlkmix
; essa é a permissão padrão para unidades de propriedade do convidado em /media
. Estes representam Read, Write, Link, locK, Memory-map e Inherit-eXecute: o último dá privilégios de execução, mas especifica que a execução deve acontecer dentro do atual confinamento (assim você não pode sair das restrições de convidado por executando um script de shell especialmente criado).