Você usa $PrivDropToGroup ou $PrivDropToGroupID no arquivo de configuração? Esse grupo tem acesso de gravação aos terminais dos usuários (por padrão, esse será o grupo tty )? Note que (com base na minha leitura do link ) se qualquer um desses itens for especificado, todos os grupos secundários serão descartados.
Os terminais dos usuários podem ser gravados por esse grupo? Seus usuários executam mesg n para desativar isso? Para verificar isso, tente o seguinte ...
-bash-4.1$ tty
/dev/pts/0
-bash-4.1$ ls -l /dev/pts/0
crw--w----. 1 sph9 tty 136, 0 Mar 23 22:59 /dev/pts/0
Para o rsyslog poder gravar nos terminais dos usuários, ele precisa estar rodando como root (o que você diz que quer evitar) ou estar rodando com o grupo que possui acesso de escrita. O exemplo acima é de uma máquina CentOS, você pode descobrir que algumas outras distribuições têm mais permissões abertas (uma caixa do Arch Linux que eu observei tinha acesso de gravação para grupos e outros).
Portanto, se cada terminal for apenas gravável pelo usuário conectado e os membros do grupo tty e rsyslogd estiverem sendo executados como usuário syslog group syslog , não será possível escreva nos terminais. Você poderia (eu acho) testar esta teoria mudando temporariamente o grupo em um de seus ttys (substituindo pts / 0 como apropriado) ...
chgrp rsyslog /dev/pts/0
Se isso funcionar, você pode tentar configurar o rsyslog para ser executado como grupo tty (embora isso possa quebrar outras coisas, se você estiver contando com arquivos de log pertencentes a um grupo específico).
Observe que tudo isso é baseado em uma rápida leitura dos documentos do rsyslog e na experiência de como isso funciona em geral, em vez de experiência específica com versões recentes do rsyslog.
As sessões de login dos usuários são registradas corretamente em utmp? (ou seja, eles aparecem na saída de w ?). Acabou de encontrar o link que sugere que houve um problema com o AppArmor, o rsyslogd e o utmp mas isso é com uma versão anterior.