Gerenciamento de usuários e permissões no MySQL 8.0: roles e privilégios
Gabarito: ERRADO. No MySQL 8.0, quando um usuário recebe privilégios por meio de uma role ativada automaticamente no login (SET DEFAULT ROLE ALL), os privilégios herdados são aplicáveis a procedimentos armazenados criados antes da associação da role, desde que o usuário tenha o privilégio EXECUTE sobre eles. A afirmação de que seria necessária uma reatribuição explícita via GRANT OPTION para refletir o novo contexto de execução é incorreta — o GRANT OPTION é um privilégio específico que permite a um usuário conceder seus privilégios a outros, não sendo exigido para que roles funcionem com objetos pré-existentes.
O gerenciamento de permissões em bancos de dados relacionais é um tema central da administração de SGBDs. No MySQL, o controle de acesso é feito por meio de privilégios concedidos diretamente a usuários ou, a partir da versão 8.0, por meio de roles (funções). Uma role é um conjunto nomeado de privilégios que pode ser atribuído a um ou mais usuários, facilitando a administração quando muitos usuários precisam dos mesmos acessos. Em vez de conceder cada privilégio individualmente a cada usuário, o administrador cria uma role, concede os privilégios a ela e, depois, atribui a role aos usuários.
A ativação de roles pode ser feita de duas formas: manualmente, com o comando SET ROLE, ou automaticamente, no momento do login, usando SET DEFAULT ROLE. Quando se define SET DEFAULT ROLE ALL, todas as roles atribuídas ao usuário são ativadas automaticamente quando ele se conecta ao servidor. Isso significa que, ao fazer login, o usuário já possui todos os privilégios das roles que lhe foram atribuídas, sem precisar executar SET ROLE manualmente.
A questão aborda um ponto específico: se os privilégios herdados de uma role ativada automaticamente se aplicam a procedimentos armazenados criados antes da associação da role. A resposta é sim, eles se aplicam. O MySQL verifica os privilégios do usuário no momento da execução do procedimento, não no momento da criação. Portanto, se um usuário tinha o privilégio EXECUTE sobre um procedimento antes de receber a role, ou se a role concedida inclui esse privilégio, ele poderá executar o procedimento normalmente, mesmo que o procedimento tenha sido criado antes da associação da role. Não há necessidade de reatribuir privilégios via GRANT OPTION.
O GRANT OPTION é um privilégio especial que permite ao seu detentor conceder a outros usuários os privilégios que ele próprio possui. Ele não é um mecanismo para "atualizar" privilégios em objetos existentes, mas sim um mecanismo de delegação de autoridade. Confundir GRANT OPTION com a necessidade de reatribuir privilégios para roles é um erro conceitual comum, explorado pela banca nesta questão.
Para fixar o entendimento, veja a comparação entre os conceitos envolvidos:
Conceito | Descrição |
|---|
Role | Conjunto nomeado de privilégios que pode ser atribuído a usuários. |
SET DEFAULT ROLE ALL | Ativa automaticamente todas as roles atribuídas ao usuário no login. |
GRANT OPTION | Privilégio que permite ao usuário conceder seus privilégios a outros usuários. |
EXECUTE | Privilégio necessário para executar um procedimento armazenado. |
A pegadinha da questão está em sugerir que objetos criados antes da associação da role não seriam afetados pelos novos privilégios, o que é falso. A verificação de privilégios no MySQL é dinâmica e ocorre no momento da execução. Portanto, a afirmação está errada.
Item — ❌ ERRADO
A afirmação está incorreta porque os privilégios herdados de uma role ativada automaticamente são aplicáveis a procedimentos armazenados criados antes da associação da role. O MySQL verifica os privilégios no momento da execução, não no momento da criação do objeto. Além disso, o GRANT OPTION não é um mecanismo para "reatribuir" privilégios a objetos existentes; ele é um privilégio que permite delegar a outros usuários os privilégios que se possui. A necessidade de reatribuição explícita via GRANT OPTION não existe nesse contexto.
Gabarito: ERRADO