Onde as ACLs de revendedores ficam salvas no WHM: análise técnica, source of truth e troubleshooting em produção

Em operação com cPanel/WHM, controle de privilégios de revendedor é um ponto de segurança de primeira linha. O problema é que a interface nem sempre reflete, de forma imediata e consistente, o estado real em disco.

Neste artigo, documento um incidente real onde uma ACL nomeada criada pela GUI não persistia como esperado, além do fluxo técnico que usei para diagnosticar, validar e padronizar a criação dessas ACLs com confiabilidade operacional.

1) Anatomia das ACLs no WHM

No contexto de revenda, o cPanel trabalha com dois modelos:

• ACL ad hoc por usuário revendedor.
• ACL nomeada (template reutilizável para múltiplos revendedores).

As permissões representam capacidades operacionais como criação de contas, gestão DNS, SSL, quotas, entre outras.

2) Source of truth: onde fica salvo

Na prática de campo, o ponto central para ACL de revendedores é:

/var/cpanel/resellers

Validação direta:

cat /var/cpanel/resellers

Cada linha representa associação de privilégios para usuário/template, com flags separadas por vírgula. Quando a ACL não aparece nesse arquivo, a persistência não foi concluída no backend.

3) Sintoma observado: ACL “sumindo” após criação

No caso real:

1. ACL foi criada em Edit Reseller Nameservers and Privileges.
2. Nome da ACL foi informado no campo de nova lista.
3. A GUI mostrou feedback parcial de sucesso.
4. Após refresh/reabertura, ACL não estava disponível para reaplicação.

No backend, a entrada também não estava consolidada no /var/cpanel/resellers.

4) Causa operacional mais comum

Falha de commit no fluxo da interface, geralmente quando:

• a lista é nomeada, mas o operador não finaliza com o botão principal de persistência;
• o fluxo de página não completa refresh final;
• sessão/latência causa estado inconsistente entre UI e gravação real.

Em outras palavras: salvar nome da lista sem concluir o commit global pode não materializar a ACL no estado final do servidor.

5) Checklist de diagnóstico senior (SSH)

Quando houver suspeita de ACL fantasma, execute:

5.1 Estado via API

whmapi1 listacls --output=jsonpretty

Se a ACL nomeada não aparece no retorno, considere não persistida.

5.2 Busca de referência no diretório cPanel

grep -R "nome_da_acl" /var/cpanel/

Útil para confirmar se houve rastro parcial em arquivos auxiliares.

5.3 Integridade básica do arquivo

ls -l /var/cpanel/resellers
stat /var/cpanel/resellers

Verificar owner, group e modo. Em ambiente padrão, manter controle estrito com root e permissões consistentes.

6) Fluxo correto via GUI (quando usar interface)

Fluxo seguro que adotei:

1. Selecionar todas as permissões da ACL alvo.
2. Informar nome da nova ACL.
3. Finalizar obrigatoriamente com Save All Settings.
4. Aguardar refresh completo da página.
5. Revalidar por API (listacls) e por arquivo (cat /var/cpanel/resellers).

Sem essa validação pós-save, você opera no escuro.

7) Fluxo recomendado para produção: WHM API 1

Para previsibilidade e automação, padronizei criação por CLI/API:

whmapi1 saveacllist \
  acllist=jvx_n1 \
  acl-list-accts=1 \
  acl-park-dns=1 \
  acl-ssl=1 \
  acl-wp-toolkit=1

Depois, aplicar em usuário revendedor:

whmapi1 setacls reseller=usuario_exemplo acllist=jvx_n1

Esse caminho reduz erro humano e remove dependência de estado da GUI.

8) Validação pós-aplicação (obrigatória)

Após saveacllist + setacls, validar:

whmapi1 listacls --output=jsonpretty
whmapi1 listresellers --output=jsonpretty
grep -R "jvx_n1" /var/cpanel/resellers

E, quando necessário, testar comportamento efetivo com login do revendedor:

• checar se menus proibidos não aparecem;
• confirmar que operações permitidas executam sem erro de ACL.

9) Boas práticas de segurança e operação

9.1 Backup antes de qualquer mudança

cp -p /var/cpanel/resellers /var/cpanel/resellers.$(date +%F-%H%M%S).bak

9.2 Evitar edição manual direta

Embora possível, editar /var/cpanel/resellers manualmente aumenta risco de sintaxe inválida e efeitos colaterais em múltiplos revendedores.

9.3 Tratar ACL como código operacional

• manter catálogo de ACLs nomeadas;
• versionar comandos whmapi1 saveacllist em repositório interno;
• usar runbook de validação pós-change.

9.4 Auditoria de mudanças

Registrar quem criou/alterou ACL, horário e finalidade operacional. Em incidentes de permissão indevida, essa trilha reduz MTTR.

10) Runbook rápido para incidente de ACL fantasma

# 1) verificar se ACL existe de fato
whmapi1 listacls --output=jsonpretty | grep -i "jvx_n1"

# 2) confirmar estado em disco
grep -R "jvx_n1" /var/cpanel/resellers

# 3) recriar ACL por API (idempotência operacional)
whmapi1 saveacllist acllist=jvx_n1 acl-list-accts=1 acl-park-dns=1 acl-ssl=1 acl-wp-toolkit=1

# 4) reaplicar ao revendedor
whmapi1 setacls reseller=usuario_exemplo acllist=jvx_n1

# 5) validar novamente
whmapi1 listacls --output=jsonpretty | grep -i "jvx_n1"

Conclusão técnica

Quando ACL “desaparece” no WHM, o problema quase sempre é persistência incompleta no fluxo da interface, não ausência de funcionalidade do backend.

O ponto-chave é tratar /var/cpanel/resellers como fonte da verdade operacional e adotar API (saveacllist/setacls) como padrão de produção. Isso aumenta previsibilidade, reduz erro manual e mantém governança de acesso em nível profissional.

Este post está licenciado sob CC BY-NC.