como deletar arquivos da pasta /dev/shm criados por uma aplicação de outro usuário? (problemas com s

LeandroVentrue
(usa Ubuntu)

Enviado em 17/01/2017 - 11:51h

Olá pessoal!

Tenho dois codigos C um chamado "producer.c" que roda no usuário "Auser" e um chamado "consumer.c" que roda no usuário "Buser".
Coloquei ambos os usuários no grupo "ABgroup" editando o arquivo /etc/group, adicionando a linha:
ABgroup:x:1234:Auser,Buser

O producer.c cria dois arquivos na pasta dev/shm, um arquivo de semáforo chamado "semaphore0" e um de shared memory chamado "sharedmem0" e coloca ambos os arquivos como pertencentes ao grupo "ABgroup". Após rodar o producer, ao usar o comando ls -lah no diretório /dev/shm, obtenho a resposta:

drwxrwxrwt  2 root    root      220 Jan 16 11:20 .

drwxr-xr-x 25 root    root      840 Jan 13 15:57 ..

-rw-rw----  1 Auser    ABgroup  12 Jan 16 11:26 sharedmem0

-rw-rw----  1 Auser    ABgroup  16 Jan 16 11:20 sem.semaphore0 

Usando então o código "consumer.c", após fazer a leitura dos dados uso a seguinte rotina para tentar deletar os arquivos de semáforo e de shm:

   

   char SEM_NAME[] = "semaphore0";

   char SHM_NAME[] = "/sharedmem0";

   sem_t *mutex;

   typedef struct {

       int temperatura;

       int nível;

       int Status;

   } data;



  void deletaArquivosSEMSHM(void){

      munmap(ptr,sizeof(data));

      shm_unlink(SHM_NAME);

      sem_close(mutex);

      sem_unlink(SEM_NAME);

   }

 

O problema é que quando rodo o "consumer.c" no usuário "Buser", os arquivos não são apagados, porém, se rodo o "consumer.c" no usuário "Auser" ambos os arquivos são deletados através da rotina acima.

Pesquisando nos fóruns e paginas por ai, descobri que esse comportamento tem relação com o fato do "sticky bit" do diretório /dev/shm estar setado. Tanto que, se aplico o comando: sudo chmod -R 0777 /dev/shm, consigo apagar os arquivos rodando o consumer.c no usuário "Buser". Ao alterar as permissões da pasta /dev/shm, elas ficam:

drwxrwxrwx  2 root    root      220 Jan 16 11:20 .

drwxr-xr-x 25 root    root      840 Jan 13 15:57 ..

-rwxrwxrwx  1 Auser    ABgroup  12 Jan 16 11:26 sharedmem0

-rwxrwxrwx  1 Auser    ABgroup  16 Jan 16 11:20 sem.semaphore0 

Pelo que entendi, quando o sticky bit de um diretório esta setado, um dado usário não pode apagar arquivos criados por outros usuários nesse diretório, ainda que os usuários e arquivos pertençam a um mesmo grupo. fonte: https://www.gnu.org/software/libc/manual/html_node/Permission-Bits.html#Permission-Bits

Para tentar solucionar o problema sem alterar as permissões do diretório /dev/shm constantemente para 0777, tentei usar o código abaixo, porém, o mesmo só funciona quando rodo o consumer.c como root ( http://man7.org/linux/man-pages/man3/chmod.3p.html ):

   

   char SEM_NAME[] = "semaphore0";

   char SHM_NAME[] = "/sharedmem0";

   const char DEV_SHM_path[] = "/dev/shm/"

   sem_t *mutex;

   typedef struct {

       int temperatura;

       int nível;

       int Status;

   } data;



  void deletaArquivosSEMSHM(void){

      chmod(DEV_SHM_path, 0777);

      munmap(ptr,sizeof(data));

      shm_unlink(SHM_NAME);

      sem_close(mutex);

      sem_unlink(SEM_NAME);

      chmod(DEV_SHM_path, 1777);

   }

 

Alguém possui alguma sugestão de como contornar as limitações impostas pelo sticky bit apenas no momento em que preciso apagar estes arquivos?

Obrigado.

paulo1205
(usa Ubuntu)

Enviado em 18/01/2017 - 06:40h

Eu não recomendo mudar permissões de diretórios do sistema.

Duas ideias que me ocorrem são: (1) usar ACLs, e (2) criar um subdiretório para a sua aplicação de IPC, colocando nesse subdiretório o modo 0770 (ou 0775), de modo que todos os membros do grupo possam manipular seu conteúdo.