Olá, alarcon
eu achei importante fazer as alterações, pois tive a oportunidade de testar em mais de um sistema e vi que, sem certas alterações, alguns não funcionavam sem reiniciar o modem após o início do sistema (ele era visto como ativo pelo gnome-ppp mas travava na discagem - às vezes até conectava, mas o início do pppd gerava um erro e por isso a conexão não obtinha IP/DNS). Além disso, creio que as alterações feitas não trazem risco, e vou destacar o que você citou (levando em consideração o que eu pensei quanto aos arquivos no momento de escrever o instalador):
- acrescentar o usuário do grupo dip:
Os grupos dip, dialout e uucp são, historicamente, grupos responsáveis pela autorização de acesso a dispositivos de comunicação em geral no mundo unix. Outros drivers, mesmo os trazidos em pacotes .deb, se encarregam de adicionar o usuário que está instalando-o ao grupo que tem acesso ao dispositivo.
- alterar a permissão do pppd (e adicionar ao grupo dip):
O pppd é o executável responsável por fazer a "tradução" dos dados trocados pelo modem. Outros fazem suas vezes, como o pon. Independente do programa a ser utilizado, é importante que o usuário que esteja fazendo uma conexão tenha plenos poderes, se não de todo o sistema (root ou outro superusuário) ao menos ao próprio aplicativo encarregado de fazê-lo. Se o pppd já não vem por padrão como pertencente ao grupo dip, o script o faz. Não verifiquei outras versões do Ubuntu então apenas me preveni de eventuais problemas, caso não venha, assim como acontece de o wvdial não vir mais por padrão, etc.
A permisão 4755 faz com que: todos os usuários possam acessá-lo/executá-lo, mas somente o root possa alterá-lo. Não posso limitar o pppd a um grupo pois há sistemas que usam o dialout ou outros grupos. Se eu o mantivesse como 4750 (sem acesso pelos usuários que não fossem do mesmo grupo do arquivo - que eu alterei para dip), poderia causar conflitos com posteriores drivers/instaladores utilizados pelo usuários que presumissem justamente isso: que o arquivo já é pertencente a determinado grupo e, por isso, não conseguissem acessá-lo.
- alterar permissões dos arquivos pap-secrets e chap-secrets: estes arquivos são encarregados de manter as senhas de conexão aos provedores. O wvdial adiciona nele as senhas antes de chamá-lo, ao final da discagem (diretamente ou via gnome-ppp), para fazer a autenticação. Protegendo os arquivos com a permissão 0660, limito o acesso a esses arquivos pelo grupo dip, ao qual eu atribuo o arquivo. Se eu não fizesse assim, na alteração da senha do usuário (no provedor de internet), poderiam ocorrer problemas, pois nem a antiga e nem a nova senha funcionariam (uma por não ser mais a senha correta, frente ao provedor, e outra por ser ignorada pelo pppd, pois o usuário não teria permissão para alterar o /etc/ppp/pap-secrets antes da autenticação ser feita, o que levaria o pppd a continuar se autenticando com a antiga ou gerando um erro de execução). Dando o acesso ao grupo dip, quando o discador gnome-ppp for chamado por um membro do grupo dip, a senha pode ser alterada diretamente no campo "senha" do discador e o arquivo refletirá a alteração, sem maiores complicações. Como o arquivo só é acessível pelos membros do grupo dip, se alguém está nele é porque pretende-se que ele seja capaz de efetuar uma conexão.
Mas a questão que você levantou é interessante... e você tem sua razão em questionar: usuários do grupo dip podem ler o arquivo pap-secrets obtendo senha de outros, já que ficam todas no mesmo lugar. Entretanto, creio que este arquivo já vem atribuído a um dos grupos de discagem, pois do contrário, somente o root poderia efetuar discagens através do pppd (e, consequentemente, do wvdial e do gnome-ppp). Se alguém puder confirmar isto num sistema recém-instalado antes que eu tenha a oportunidade de testar por conta própria, eu agradeço. Se for constatado que estes arquivos não são, por padrão, de um destes grupos, vou adicionar ao script a opção de não dar acesso ao grupo dip e gravar a senha diretamente nos arquivos pap-secrets e chap-secrets, assim como o seu script faz (posto aqui amanhã).
Além disso, ressalto que apesar de que dispositivos de comunicação são normalmente atribuídos ao grupo uucp somente em sistemas baseados em RPM (CentOS, Red Hat, Fedora, etc), enquanto em sistemas Debian são atribuídos ao grupo dialout, isto aconteceu no meu notebook*, que tem um modem SiS (chipset 630), por isso resolvi adicionar o usuário também ao grupo uucp. Mal, não faz. Se faz bem, também não sei afirmar com certeza. Talvez seja psicológico, pois não tive muito tempo para testar depois que fiz esta alteração aqui no meu sistema, mas nas poucas conexões que fiz nos últimos 3 dias, tenho a impressão de que ficou mais estável, mesmo usando a string padrão (na verdade, a conexão não caiu nenhuma vez, mesmo depois de desconectar manualmente e reconectar usando o sl-modem-daemon para reativação - o que ainda é necessário, no caso do meu modem - chegando a ficar 6 horas conectado direto), o que só acontecia quando eu conectava chamando o discador com sudo (ou executando-o como root).
*Isto eu verifiquei numa das consultas ao arquivo /var/log/messages, onde li Jun 15 22:27:30 renato-laptop pppd[3525]: Connect: ppp0 <--> /dev/pts/0 e, então, verificando o dispositivo com ls -lh /dev/pts, obtive crw-rw-rw- 1 root uucp 136, 0 2009-06-15 22:27 0, ou seja, vi que /dev/pts/0 é pertencente ao usuário root, grupo uccp.
De qualquer forma, saliento que todas as alterações feitas no sistemas são exibidas no terminal durante a execução do instalador. Antes de implementar as barras de progresso do zenity, até mesmo os processos do dpkg e as compilações do make(gcc) eram exibidas por inteiro (e não somente as mensagens de alerta/erro) - então se alguém souber como fazer para a saída continuar aparecendo, seria de grande valia.
Atenciosamente,
Renato
Tópico: Instalador Automático do Modem Smartlink para Ubuntu (Lida 15917 vezes)