You are on page 1of 32

Administrao de sistemas Unix

Introduo
Os sistemas Unix sempre representaram uma opo importante quando se pretende fiabilidade e eficincia, embora existam muitas implementaes especificas de determinados fabricantes (HP UX, IBM AIX, Digital ULTRIX, Digital UNIX, Novell UnixWare, SCO Unix, ...) todas elas mantm um elevado grau de compatibilidade baseada no compilador de linguagem C, um conjunto de bibliotecas compativeis e um ncleo de sistema operativo (kernel) com conceitos que caracterizam os sistemas operativos tipo Unix. Embora no exista compatibilidade binria entre os diversos sistemas tipo Unix, existe compatibilidade de cdigo fonte, isto significa que o "software" desenvolvido em linguagem C para uma dada plataforma Unix pode ser "compilado" em qualquer outra plataforma Unix. Mais recentemente o projecto aberto Linux tem-se assumido como uma alternativa de enorme importncia, com um ncleo desenvolvido de forma aberta ("open source"), encontra-se disponvel de forma mais ou menos gratuita, atravs de diversas distribues. Estas distribues Linux, alm do ncleo, incluem todo o "software" adicional e ficheiros necessrios para o funcionamento do sistema, a maioria deste "software" adicional tambm desenvolvido em "open source". Sem tomar qualquer partido, algumas das distribuies mais tradicionais so: Slackware, Redhat e Suse.

Administrao de sistemas Linux


Dada a sua importancia actual, a maioria da informao constante neste documento baseiase em Linux, contudo a administrao de outros sistemas Unix no difere quase nada da administrao de sistema Linux. Com o seu carcter "open source", o sistema operativo Linux recebe as mais diversas contribuies e actualmente a implementao Unix mais verstil, suportando as mais diversas possibilidades de configurao e integrao. Administrar sistemas Linux pode ser um desafio significativo, normalmente os projectos "open source" produzem dois tipos de produto, "verso estvel" e "verso em desenvolvimento/instavel", se o administrador se restringir utilizao das verses estveis, tem certas garantias de uma existncia pacfica, se pelo contrrio tentar utilizar verses em desnvolvimento, corre riscos de instabilidade no respectivo sistema e possvelmente acabar a colaborar no desenvolvimento desses projectos. Por uma questo de metodologia, a administrao de um sistema operatvo pode ser dividida em vrias reas distintas:

Administrao de utilizadores - criar e modificar as definies relacionadas com os utilizadores do sistema: identificao interna; nome de utilizador; chave de acesso; grupos a que pertence; etc. Administrao de sistemas de ficheiros - gerir o sistema de ficheiros, integrando diversos suportes fsicos e gerir as permisses dos utilizadores sobre os ficheiros. Administrao de "software" - gerir as aplicaes disponveis no sistema, a maioria das aplicaes destinam-se aos utilizadores, mas por exemplo, podem tambm servir para a implementao de servios. Administrao de servios - gerir servios, com especial destaque para os servios de rede.

Na realidade todas estas reas esto intimamente relacionadas entre s

Administrao de utilizadores
Qualquer sistema multi-utilizador tem de manter uma base de dados de utilizadores, nesta base de dados, geralmente de tipo relacional, existe um registo para cada utilizador. Cada utilizador tem diversas propriedades associadas a s, para gerir os utilizadores e todo o sistema em geral existe um "super-utilizador" ou administrador, nos sistemas Unix existe um nico administrador que tem o nome "root". Nos sistemas tipo Unix os utilizadores esto definidos no ficheiro /etc/passwd, neste ficheiro de texto, cada linha corresponde a um utilizador, constando uma sequencia de campos, separados por dois pontos, todos os campos so obrigatrios, mas alguns podem estar vazios. O exemplo seguinte ilustra um extracto de 8 linhas (8 utilizadores) de um ficheiro /etc/passwd:
root:BeDyr8qulmhZ2:0:0:root:/root:/bin/bash daemon:*:2:2:daemon:/sbin:/bin/bash bin:*:1:1:bin:/bin:/bin/bash postgres:*:26:2:Postgres Database Admin:/var/lib/pgsql:/bin/bash wwwrun:*:30:65534:Daemon user for apache:/tmp:/bin/bash empress:*:35:2:Empress Database Admin:/usr/empress:/bin/bash guest:a28HqK3Yamh7t:1001:102:Utilizador nosso convidado:/home/guest:/bin/csh user:uHr5fg6RtEw23:1002:102:Utilizador local:/home/user:/bin/bash +

Os campos so, ordenadamente, os seguintes:


"Login Name" ou "Username" - o nome que o utilizador usa para se identificar perante o sistema, logo deve ser nico no sistema. SALT+HASH(SALT+PASSWORD) - o resultado da aplicao de uma funo de "hash" password do utilizador (em conjunto com o SALT que introduz um factor aleatrio). usado para autenticao do utilizador, para o efeito o utilizador fornece o seu "Username" e respectiva PASSWORD, o sistema calcula ento

HASH(SALT+PASSWORD) e verifica se coincide com o que est no ficheiro /etc/passwd. Neste campo, separados por virgulas podem ainda constar diversos valores referentes validade da password, ver o ficheiro /etc/shadow. User Identifier (UID) - um nmero inteiro usado para identificar o utilizador no interior do sistema, tal como o "Username" deve ser nico, contudo ao contrrio do "Username" que apenas consta no ficheiro /etc/passwd e usado apenas para a identificao inicial perante o sistema, o UID intensivamente usado nas operaes internas ps-login. Como se pode observar o UID do utilizador "root" zero, e dever existir em todos os sistemas tipo Unix. Group Identifier (GID) - nmero inteiro que identifica o grupo primrio a que o utilizador pertence, em Unix os grupos de utizadores esto definidos no ficheiro /etc/group, sendo que cada grupo possui um nmero de identificao nico, o GID. Nome completo do utilizador Localizao do directrio de trabalho - trata-se do nome do directrio de trabalho a atribuir aps a entrada no sistema, tipicamente um directrio pessoal no qual apenas esse utilizador tem permisses, tem habitualmente a designao de HOME. Nome da shell inicial - quando o utilizador entra no sistema (depois da autenticao) o controlo da sesso tem de ser transferido para um programa que ser executado j com as permisses desse utilizador, tipicamente um programa interactivo interpretador de comandos em modo de texto, que tem a designao de "shell".

Grupos de utilizadores A definio de grupos de utilizadores muito vantajosa sob o ponto de vista de administrao porque quando se pretende atribuir a muitos utilizadores um dado direito (permisso) possvel atribuir esse direito ao grupo, tendo como efeito que todos os utilizadores que so membros do grupo passam tambm a usufruir desse direito. Nos sistemas Unix os grupos esto definidos no ficheiro /etc/group, este ficheiro tem uma estrutura semalhante do /etc/passwd, os campos so os seguintes:

O 1 campo define o nome do grupo, tal como para utilizadores este campo tem de ter um valor nico. Normalmente no se usam passwords para grupos, por isso o 2 campo tem um "*" ou um "x". O 3 campo contm o GID, tal como acontecia no /etc/passwd para os UID, os GID tem de ser nicos no sistema. O 4 e ltimo campo possui uma lista de utilizadores (separados por virgula) que pertencem ao grupo, isto apenas necessrio para os utilizadores que no tm o grupo mencionado como grupo primrio no /etc/passwd.

A seguir apresenta-se um extracto de um ficheiro /etc/group:


root:x:0:root bin:x:1:root,bin,daemon daemon:x:2:

users:x:102: nogroup:x:65534:root

Pode observar-se que apesar do grupo "users" no ter membros definidos, na realidade, por cruzamento com o exemplo /etc/passwd anterior, os utilizadores "guest" e "user" so membros. Outro aspecto a destacar a existncia de um grupo chamado "root", se forem colocados utilizadores neste grupo, eles passaro a ter muitos dos direitos que o administrador possui sobre objectos do sistema, j que este o grupo primrio do administrador. Shadow passwd Um dos problemas suscitados pelo ficheiro /etc/passwd o facto de ter de ser legivel para todos os utilizadores. Uma vez que o HASH da password consta no ficheiro, torna-se possvel tentar "adivinhar" uma "password" que gera esse HASH, possivelmente no ser a mesma "password" que o utilizador usa, mas servir como autenticao. Quebrar desta forma o mecanismo de autenticao extremamente difcil e moroso, a abordagem que usada na prtica consiste em usar um programa gerador de "passwords", baseado por exemplo num dicionrio e tentar essas "passwords". Seja como for o acesso aos "hash" das "passwords" dos utilizadores claramente um ponto fraco, o processo de tentativa de autenticao que deveria ser controlado pelo sistema (controlando o nmero mximo de tentativas e o atraso entre tentativas) pode ser simulado em outro sistema, basta para isso que o "hash" que consta no /etc/passwd seja copiado. Para resolver este problema de segurana, existe a possibilidade de utilizar um ficheiro sombra para armazenar os hash das "passwords", este ficheiro /etc/shadow, mas ao contrrio do ficheiro /etc/passwd apenas legivel pelo utilizador "root". A designao "shadow" (sombra) deve-se ao facto de conter exactamente os mesmos registos do /etc/passwd. O ficheiro /etc/shadow tem uma estrutura semelhante ao /etc/passwd, mas os campos so os previstos para o campo da password no ficheiro /etc/passwd. Os campos, ordenadamente, so os seguintes:

"Login Name" ou "Username" - o nome que o utilizador exactamente igual ao que se encontra no ficheiro /etc/passwd. SALT+HASH(SALT+PASSWORD) - o resultado da aplicao de uma funo de "hash" password do utilizador, tal como foi descrito para o ficheiro /etc/passwd, a respectiva entrada no ficheiro /etc/passwd passa agora a conter um "x". Data da ltima mudana de password - especificada em nmero de dias, desde 01/01/1970. Nmero de dias que faltam para o utilizador poder mudar a password. Nmero de dias que faltam para o utilizador ser obrigado a mudar a password (a password expira).

Nmero de dias antes de ser obrigado a mudar a password em que o utilizador comea a ser avisado. Nmero de dias decorridos depois da a password expirar em que a conta desactivada. Data em que a conta foi desactivada - especificada em nmero de dias, desde 01/01/1970. Campo no especificado, reservado para uso futuro.

Gesto das bases de dados de utilizadores Unix Existem diversos programas que podem ser usados para gerir os utilizadores, aqui vou apenas referir os programas bsicos, que devem estar disponveis em todos os tipos de sistema Unix, existem depois muitos outros programas que usam os primeiros e que so especificos de cada sistema em particular, muitos deles com interface grfica. Na realidade para administrar utilizadores em Unix basta um editor de texto, de preferncia o "vi", o nico campo que no pode ser editado directamente o "hash" da password, para isso necessrio recorrer ao programa "passwd". Em sistemas onde se usa "shadow passwords", depois de modificar manualmente o /etc/passwd necessrio ainda invocar o programa "pwconv". O "pwconv" cria no directrio corrente um ficheiro "npasswd" e um "nshadow" que correspondem s novas verses dos ficheiros /etc/passwd e /etc/shadow depois de realizada a juno da informao. Os utilizadores podem alterar alguns aspectos da sua conta, o administrador pode alterar qualquer conta, para o efeito os programas seguintes verificam se quem os est a executar o administrador ou no:

passwd - permite alterar a password do utilizador, permite ainda ao administrador gerir os parmetros suplementares do ficheiro /etc/shadow. chfn ("Change full-name") - permite alterar o nome completo do utilizador. chsh ("Change shell") - permite alterar o programa inicial do utilizador.

Geralmente todos os sistemas dispem de programas mais sofisticados para manipular utlizadores, a utilizao destes programas est geralmente reservada ao administrador:

useradd - permite adicionar novos utilizadores, procura automticamente um UID no usado e cria a "home directory", os utilizadores so criados segundo um "template", ou especificando as diversas caracteristicas na linha de comando. userdel - permite remover um utilizador e pode tambm remover a "home directory". usermod - permite alterar qualquer dado relacionado com um utilizador, incluindo o "username" e mesmo o UID, bem como grupos a que pertence. groupadd - criao de novos grupos de utilizadores. groupmod - modificao de grupos de utilizadores (nome do grupo e GID). groupdel - eliminao de grupos de utilizadores.

A utilizao de programas especificos mais razovel do que a edio manual, estes programas especificos garante a excluso mtua para escrita, isto garantem que nunca existem dois programas a alterar simultaneamente as bases de dados dos utilizadores, com os resultados imprevisiveis que da podem resultar, por outro lado a edio manual pode, por erro do administrador levar a que os ficheiros no respeitem a formatao ou no sejam coerentes. Tratando-se da base de dados dos utilizadores estes erros podem ser muito graves. Bases de dados de utilizadores centralizadas - NIS Com a rpida evoluao das redes de computadores, em grande parte impulsionadas pelos sistemas operativos Unix, tornou-se absolutamente necessrio criar sistemas centralizados para estas bases de dados que evitassem uma gesto independente para cada mquina de uma rede, o mais tradicional em ambiente Unix o sistema conhecido por "Yellow Pages" (yp) ou NIS ("Network Information Service"). Este sistema composto por um servidor "ypserv", instalado numa mquina central por clientes "ypbind" instalados nas outras mquinas. Os vrios clientes (ypbind) contactam o servidor para obterem mapas, que no so mais do que equivalentes dos contedos habituais dos ficheiros /etc/passwd, /etc/group e outros, como por exemplo o /etc/hosts ou o /etc/services. O servidor (ypserv) no usa directamente os ficheiros locais para responder aos clientes, existem programas (geralmente invocados atravs do comando "make" no directrio /var/yp) que convertem a informao residente nos ficheiros locais (aqui vistos como ficheiros fonte) para um formato adequado ao servidor. Os ficheiros fonte podem ou no ser as verses em uso local no servidor (localizadas no directrio /etc), se forem usadas como fonte as verses locais existe a grande vantagem de poderem ser usados os programas de gesto de utilizadores atrs referidos, apenas necessrio no esquecer de, aps as alteraes, invocar o comando "make" no directrio /var/yp para actualizar a base de dados NIS. A desvantagem desta opo que os utilizadores de sistema, tais como root, daemon, field, ... tambm vo ser colocados na base de dados. A opo por ficheiros separados como fonte NIS (noutro directrio que no /etc) implica a necessidade de se usar programas especificos para gesto de utilizadores que permitam a manipulao dos ficheiros noutros directrios, estes programas no abundam. Os clientes NIS utilizam o programa ypbind direccionado para o servidor NIS, para que na autenticao dos utilizadores o servidor NIS seja consultado necessrio que a ltima linha dos ficheiros locais (/etc/passwd, /etc/group e /etc/shadow) contenha o sinal "+", que significa adicionar toda a informao do servidor NIS (tambm possivel adicionar utilizadores NIS individuais, usando linhas contendo "+username". Nos clientes NIS ainda possvel usar vrios comandos tais como o "ypcat" para consultar os vrios mapas disponibilizados pelo servidor NIS, ou o "ypmatch" para pesquisar os mapas.

O servidor NIS (ypserv) apenas de leitura, para que os utilizadores possam alterar os seus dados "password/shell/nome-completo" recorre-se a um servio separado, assim conjuntamente como o "ypserv" instala-se um outro servidor, o "yppasswdd" no lado do cliente NIS utiliza-se agora os comandos yppasswd, ypchsh e ypchfn que contactam o yppasswdd no servidor NIS. Suporte a multiplas origens de dados - nsswitch Com a introduo do NIS passaram a existir nos clientes duas origens para as definies de utilizadores, as bases de dados locais (no directrio /etc) e as bases de dados NIS. A forma como se sinaliza tal facto atravs da colocao de sinais "+" nas verses locais, tal significa que naquele ponto da pesquisa local deve ser realizada uma pesquisa no servidor NIS. Para o caso da resoluo de nomes de mquinas podemos ter mesmo 3 origens diferentes para os dados: local (/etc/hosts), NIS ou DNS, os sistemas que so usados e em que ordem esto especificados no ficheiro /etc/host.conf. Os sistema Linux mais recentes expandem significativamente esta ideia, generalizando o suporte a multiplas origens para a informao de sistema, nomeadamente quanto a utilizadores. O sistema NSS ("Name Service Switch"), usa a informao constante no ficheiro /etc/nsswitch.conf para definir para cada tipo de informao, quais as origens a pesquisar e em que ordem. O NSS permite distinguir os seguintes tipos de informao de sistema: aliases, ethers, group, hosts, netgroup, network, passwd, protocols, publickey, rpc, services e shadow. Para cada um dos tipos de informao podem ser definidas as origens a pesquisar e a ordem que so pesquisadas. As origens possveis para a pesquisa so definidas de forma modular, para cada tipo de origem deve ser instalada a biblioteca apropriada, geralmente com designao do tipo libnss_SERVICE.so, onde SERVICE substituido pela designao do tipo de base da dados que pode posteriormente ser usada no /etc/nsswitch.conf. Alguns exemplos so:

libnss_files.so - bases de dados locais (/etc) libnss_compat.so - bases de dados locais ou NIS (compatibilidade com sistemas anteriores) libnss_nis.so - servidores NIS libnss_dns.so - servidores DNS libnss_ldap.so - servidores LDAP (X.500) libnss_winbind.so - servidores Microsoft (NT/2000) - Samba suite

O NSS permite um acesso transparente a diversas fontes de informao de sistema, contudo quando se trata de informaao referente a autenticao tudo se complica, no caso do NIS, as passwords so armazenadas exactamente da mesma forma que nas verses locais, mas se

queremos generalizar para outros tipos de bases de dados de sistema, certamente que vai ser necessrio suportar outros formatos. Recorde-se que mesmo para o NIS foi necessrio criar um servio separado (yppasswdd) para permitir a alterao de passwords. Para resolver o problema da autenticao com diversos tipos de bases de dados foi criado o conceito de "Pluggable Authentication Module" (PAM), trata-se de um sistema modular que por adio das bibliotecas apropriadas, geralmente residentes no directrio /lib/security, permite aos programas usar os diversos sistemas de autenticao. Os ficheiros de configurao residentes no directrio /etc/pam.d/ permitem definir para cada aplicao quais os modulos de autenticao a usar, tais como pam_ldap, pam_winbind, etc.

Administrao de sistemas de ficheiros


O sistema operativo Unix utiliza uma rvore de directrios nica, isto , no acesso aos ficheiros no existe o conceito de dispositivo de armazenamento (ex.: letras de drive), todos os dispositivos de armazenamemnto so integrados numa nica rvore de directrios. Apesar disso so suportados um grande nmero de diferentes tipos de sistemas de ficheiros residentes nos mais diversos tipos de dispositivo de armazenamento ou servidores de ficheiros, que so depois integrados numa mesma rvore de directrios. A operao de integrao de sistemas de ficheiros residentes em dispositivos distintos conseguida custa do conceito de "montagem". O sistema de ficheiros integrado comea a ser constituido atravs da montagem do directrio RAIZ, simbolizado por "/", este sempre o primeiro passo, geralmente o dispositivo que usado para este efeito um disco local, mas para mquinas "diskless" tambm pode ser um directrio residente num servidor de ficheiros, ou um disco de RAM. Uma vez montada a raiz (/) podem ser acrescentados estrutura outros sistemas de ficheiros residentes em outros dispositivos ou servidores de rede, para o efeito basta que na estrutura que j est montada exista um directrio vazio, a montagem consiste na associao do directorio vazio ao dispositivo em questo. Depois de realizada a montagem o ponto inicial do sistema de ficheiros residente no dispositivo/servidor passa a coincidir com o que antes era o directrio vazio, isto o directrio deixa de estr vazio e passa a conter a informao que se encontra no dispositivo/servidor. As montagens so permanentes at que sejam "desfeitas" (desmontagem), ficando disponveis para todos os utilizadores e aplicaes do sistema, estas operaes apenas podem ser realizadas pelo administrador (root). O comando "mount" permite, montar um sistema de ficheiros, a sua sintaxe bsica a seguinte: mount dispositivo ponto-de-montagem

A especificao do dispositivo varia de acordo com o seu tipo, os dispositivos locais esto definidos no directrio /dev, por exemplo numa mquina equipada com dois controladores IDE, os discos sero:

/dev/hda - disco MASTER do controlador 1 (ou primrio) /dev/hdb - disco SLAVE do controlador 1 (ou primrio) /dev/hdc - disco MASTER do controlador 2 (ou secundrio) /dev/hdd - disco SLAVE do controlador 2 (ou secundrio)

A maioria das formataes para os discos exige a definio de parties, mesmo que seja uma nica que ocupa todo o disco, as parties so identificadas por nmeros inteiros que se acrescentam identificao do disco, a primeira partio a 1, a segunda a 2 e assim sucessivamente, deste modo, por exemplo a terceira partio do disco MASTER do controlador secundrio identificada por /dev/hdc3. Para o caso de controladores de discos SCSI, que ao contrrios dos controladores IDE no esto limitados a dois discos, as identificaes dos discos so /dev/sda, /dev/sdb, /dev/sdc, ... . Novamente, caso existam parties nos discos, estas sero nmeradas e identificadas da mesma forma que foi descrita para os discos IDE. Os drives de disquete so identificados por /dev/fd(n), onde (n) substituido por um nmero, o equivalente ao drive A: /dev/fd0, o drive B: ser /dev/fd1. O comando mount sem argumentos devolve uma listagem das montagens correntes, esta informao mantida no ficheiro /etc/mtab, o exemplo seguinte mostra um resultado da invocao do comando mount, sem argumentos.
/dev/hda3 on / type ext2 (rw) proc on /proc type proc (rw) /dev/hda1 on /boot type ext2 (rw) /dev/hdb on /cdrom1 type iso9660 (ro) /dev/hdc1 on /usr/local2 type ext2 (rw) /dev/fd0 on /disquete type msdos (ro) //winbox/c on /mnt/doshdd type smbfs (0) linuxbox:/usr on /usr2 type nfs (rw,addr=192.168.0.2)

A informao apresentada consiste na identificao do dispositivo, ponto de montagem, tipo de sistema de ficheiros e opes de montagem, por exemplo rw=leitura/escrita e ro=leitura-apenas. Podemos verificar que a raiz do sistema de ficheiros a terceira partio do disco MASTER do controlador IDE primrio, enquanto a primeira partio do mesmo disco se encontra acessivel no directrio /boot. O nome "proc" no corresponde a nenhum dispositivo, usado pelo ncleo do sistema operativo para guardar diversa informao sobre o seu estado e deve estr sempre montado no directrio /proc.

De destacar ainda o /dev/hdb montado no directrio /cdrom1, no se trata de um disco, mas sim de um leitor de CD-ROM, o facto de os CD's no terem parties justifica o facto de no existir qualquer numerao na identificao do dispositivo, o tipo de sistema de ficheiros mais comum para os CD-ROM's o ISO9660, note-se ainda que esta montagem apenas de leitura (ro). Pode tambm observar-se que a disquete correspondente ao drive A: est montada no directrio /disquete. As duas ltimas linhas apresentadas correspondem a directrios de servidores de rede, nestes casos a forma de definir o dispositivo depende do tipo de servidor, no caso, //winbox/c corresponde a uma partilha com o nome "C", por um PC Windows/98, chamado "WINBOX", o protocolo usado o SMB (tipo de sistema de ficheiros "smbfs"), este sistema de ficheiros remoto fica acessvel no directrio /mnt/doshdd. A ltima linha corresponde montagem do directrio /usr, exportado por uma mquina chamada "LINUXBOX", usando o protocolo NFS, este sistema de ficheiros remoto fica acessvel em /usr2. O sistema operativo Unix usa intensivamente "caching" nos acessos aos sistemas de ficheiros que esto montados, para termos a certeza de que todas as alteraes sobre um sistema de ficheiros so colocadas no dispositivo, este tem de ser desmontado. Para desmontar um sistema de ficheiros usa-se o comando "umount" que recebe como argumento o nome do directrio onde o dispositivo est montado. Isto valido por exemplo para dispositivos amoviveis, especialmente se montados no modo "leitura-escrita", por exemplo para usar uma disquete temos de realizar as operaes na seguinte ordem: COLOCAR DISQUETE - MONTAR DISPOSITIVO - UTILIZAR - DESMONTAR DISPOSITIVO - RETIRAR DISQUETE. Em fases iniciais de desenvolvimento do suporte de alguns tipos de dispositivo, em especial para dispositivos correspondentes a servidores de ficheiros, pode ser necessrio recorrer a programas separados para realizar as operaes de montagem, posteriormente esse suporte integrado no sistema e pode ser usado o comando mount. O ficheiro /proc/filesystems contm a lista de tipos de sistemas de ficheiros suportados pelo ncleo do sistema operativo e que por isso podem ser montados com o comando "mount". Embora os sistemas mais recentes j possuam o suporte de "smbfs" (acesso a servidores MicroSoft) integrado, podendo ser usado o comando mount, em sistemas Linux mais antigos, ou em que o suporte de "smbfs" no foi incluido ao compilar o ncleo do sistema operativo, pode ser necessrio usar o comando smbmount. Embora no exemplificado acima, outro tipo de servidor suportado so os servidores Novell Netware, sendo nesse caso o tipo de sistema de ficheiros ncpfs, tambm neste caso, em verses mais antigas do Linux pode ser necessrio recorrer ao programa "ncpmount". Embora existam tambm equivalentes smbumount e ncpumount, o comando umount permite desmontar qualquer tipo de sistemas de ficheiros. Quando se realiza uma montagem, com recurso ao comando mount, podemos especificar o tipo de sistema de ficheiros, usando a sintaxe mount [-t tipo-fs] dispositivo directrio-de-montagem, se o tipo omitido o

comando tenta "adivinhar", para isso pode recorrer forma como "dispositivo" est especificado, ou simplesmente tentar ler do dispositivo essa informao. Alguns tipos vulgarmente suportados em Linix so:
minix - primeiro sistema para o Linux, ainda usado para disquetes e discos de RAM. ext - verso melhorada do minix, que foi actualmente substituida pelo ext2. ext2 - verso actualmente usada na maioria dos sistemas Linux. hpfs - usado pelo OS/2, em linux apenas possvel o acesso de leitura. msdos - usado pelo MS-DOS e Windows 3.xx. umsdos - sistema com suporte dos atributos necessrios ao Unix, implementada sobre uma formatao msdos. vfat - msdos com suporte de nomes longos, usada pelo Windows/95/98. proc - sistema interno, usado como interface com o ncleo do sistema operativo. nfs - acesso por rede a servidores NFS. iso9660 - usado pelos CD-ROM. smbfs - acesso por rede a servidores SMB (Samba; Windows/95/98; Windows NT; Windows 2000; ...) ncpfs - acesso por rede a servidores NCP (Novell; ...) affs- acesso por rede a servidores AMIGA. sysv - usado por outros sistemas operativos tipo Unix.

Durante o arranque ("boot") de um sistema Unix existe um conjunto de dispositivos que deve ser "montado" no sistema de ficheiros automaticamente. O ficheiro /etc/fstab contm a lista de todos os dispositivos que devem ser montados no arranque da mquina (e devem ser desmontados no encerramento da mesma). Eis um exemplo:
/dev/hda3 /dev/hda2 /dev/hda1 /dev/hdb /dev/hdc1 none / swap /boot /cdrom1 /usr/local2 /proc ext2 swap ext2 iso9660 ext2 proc defaults defaults defaults ro defaults defaults 1 0 1 0 1 0 1 0 2 0 1 0

A partio /dev/hda2 usada para SWAP (memria virtual), sendo formatada de forma apropriada para esse efeito. Embora para as parties de SWAP no exista o conceito de montagem porque essas parties no so directamente acessiveis, nem fazem parte do sistema de ficheiros, devem ser activadas durante o arranque e para isso so registadas no ficheiro /etc/fstab. Os sistemas de ficheiros em Unix, para serem completamente funcionais, necessitam de um conjunto de caracteristicas importantes em termos de caracterizao de cada entrada existente (ficheiro, directrio, ... ). Estas caracteristicas (atributos) que devem estr associadas a cada entrada (i-node), algumas das mais importantes e visveis so:

Nomes com at 255 caracteres c/ suporte de qualquer caractere e distino maiusculas/minusculas. MODO, permisses/flags (16 bits) UID, identificao do propritrio (16 bits) GID, identificao do grupo (16 bits) ATIME, data/hora do ltimo acesso (32 bits)

CTIME, data/hora em que foi criado (32 bits) MTIME, data/hora da ltima modificao (32 bits)

Nem todos os sistemas de ficheiros suportados pelo Linux obdecem a estas caracteriscas, sendo nessas situaoes realizadas adaptaes de modo a que as diferenas que transpaream sejam minimas, por exemplo se o sistema de ficheiros no suporta permisses ou outras propriedades, estes atributos sero definidos de um modo fixo no acto de montagem e o sistema montado aparenta ter esses atributos. Cada entrada num sistema de ficheiros Unix possui associada a s uma identificao de utilizador (UID) e uma identificao de grupo (GID). Quando um utilizador cria uma nova entrada (ex.: ficheiro) o UID desse utilizador fica associado ao ficheiro, bem como o GID do grupo primrio desse utilizador. O UID associado a uma entrada indica quem o proprietrio do ficheiro. Cada entrada num sistema de ficheiros Unix deve suportar o atributo MODO com capacidade para 16 bits, do bit mais significativo para o menos significativo, eles so usados da seguinte forma:

4 bits usados pelo sistema para definir o tipo de entrada no sistema de ficheiros. Em linux, adoptando a notao decimal os valores usados so: o 1 - FIFO (PIPE) o 2 - DEVICE (char) o 4 - Directrio o 6 - DEVICE (block) o 8 - Ficheiro o 10 - Ligao Simblica o 12 - Socket Estes quatro bits so manuseados apenas pelo sistema operativo.

SETUID - Alterao do UID para ficheiros executveis. SETGID - Alterao do GID para ficheiros executveis. STICKY - Utilizao especial, depende do tipo de entrada e do tipo de sistema.

OWNER READ PERMISSION - Acesso de leitura para o proprietrio. OWNER WRITE PERMISSION - Acesso de escrita para o proprietrio. OWNER EXECUTE PERMISSION - Autorizao de execuo para o proprietrio.

GROUP READ PERMISSION - Acesso de leitura para os membros do grupo. GROUP WRITE PERMISSION - Acesso de escrita para os membros do grupo.

GROUP EXECUTE PERMISSION - Autorizao de execuo para os membros do grupo.

OTHERS READ PERMISSION - Acesso de leitura para todos os utilizadores. OTHERS WRITE PERMISSION - Acesso de escrita para todos os utilizadores. OTHERS EXECUTE PERMISSION - Autorizao de execuo para todos os utilizadores.

Como foi referido os 4 bits mais significativos so reservados para o sistema e nunca so manuseados directamente, os 3 bits seguintes definem permisses especiais que se abordar mais tarde, seguem-se 3 grupos de 3 bits que definem as permisses para 3 entidades, respectivamente o proprietrio da entrada (UID), o grupo associado entrada (GID) e todos os utilizadores. Como se pode observar existem 3 direitos bsicos (permisses) LEITURA, ESCRITA e EXECUO. O significado que estas permisses assumem dependem do tipo de entrada, para os dois tipos mais comuns de entrada no sistema de ficheiros, o significado o seguinte:

FICHEIROS / LEITURA - permite vizualizar o conteudo do ficheiro. FICHEIROS / ESCRITA - permite alterar o conteudo do ficheiro. FICHEIROS / EXECUO - permite executar o ficheiro, isto interpretar o seu contedo com sendo executvel e criar um processo correspondente. DIRECTRIOS / LEITURA - permite vizualizar o conteudo do directrio (entradas). DIRECTRIOS / ESCRITA - permite alterar o conteudo do directrio (entradas). Por exemplo remover ficheiros ou alterar o respectivo nome. DIRECTRIOS / EXECUO - permite tornar o directrio o directrio corrente/de trabalho.

Para manter a segurana eficaz existem ainda as seguintes restries:


Apenas o proprietrio (ou root) pode alterar as permisses. Apenas o administrador (root) pode alterar o proprietrio. Apenas o proprietrio pode alterar o grupo, mas s se pertencer a esse novo grupo.

As permisses bsicas READ/WRITE/EXECUTE so habitualmente representadas atravs de um digito que correspondem representao decimal dos 3 bits, deste modo EXECUTE corresponde ao valor 1 (1 bit), WRITE corresponde ao valor 2 (2 bit) e READ corresponde ao valor 4 (3 bit). Exemplos: 7 representa todos os bits com valor 1, ou seja todas as permiss&otilde:es; 4 representa permisso de leitura apenas; 5 representa permisso de execuo e de leitura.

Representando na forma decimal os 3 grupos de permisses, para proprietrio, grupo e outros forma-se uma sequencia de 3 digitos. Exemplos:

644 - READ e WRITE para o proprietrio, READ para o grupo e READ para outros. 750 - READ, WRITE e EXECUTE para o proprietrio, READ e EXECUTE para o grupo e nenhuma permisso para os outros.

Este tipo de representao vulgarmente usado no comando "chmod" que permite alterar as permisses sobre uma entrada do sistema de ficheiros. A permisses podem facilmente ser visualizadas atravs do comando "ls" com output longo (ls -l), eis um exemplo de uma listagem deste tipo de um directrio /etc:
total 1318 -rw-r--r-1 root root drwxr-xr-x 2 root root -rw-r--r-1 root root lrwxrwxrwx 1 root root /usr/local/deix/SVGA_16 -r--r--r-1 root root -rw------1 root root drwxr-xr-x 2 root root -rwxr-xr-x 1 root root -rw-r--r-1 root root -rw-r--r-1 root root -rw------1 root root lrwxrwxrwx 1 root root /usr/local/samba/lib/lmhosts -rw-rw-r-1 root root -rw-r----1 root shadow -rw------1 root root -rw-r--r-1 root root lrwxrwxrwx 1 root root 9 1024 40458 23 12758 608 1024 106 3139 10137 457 28 32768 879 340 107 7 Dec 10 1999 HOSTNAME Mar 10 2001 SuSEconfig Oct 9 18:50 TextConfig Oct 14 01:23 X -> Jan Nov Oct Sep Sep Nov Jul Mar 28 2000 apsfilterrc 14 09:41 crontab 9 1999 default 22 2000 hostOff 22 2000 hostOff.log 16 15:52 hosts 27 00:04 lilo.conf 14 2001 lmhosts.rpmorig ->

Oct 9 1999 psdevtab Oct 19 11:31 shadowOct 20 12:07 ypgroup Oct 8 1998 ytalkrc Oct 9 1999 zshrc -> profile

Na coluna da esquerda so representas as permisses/modo, primeira letra indica o tipo de entrada:


(-) Ficheiro Normal (d) Directrio (l) Ligao simblica (c) Device (char) (b) Device (block) (p) FIFO (pipe) (s) Socket

As 9 letras seguintes representam as permisses para proprietrio, grupo e outros (3 letras para cada).

Quando um utilizador cria um ficheiro ou directrio, as permisses com que este criado so definidas atravs da FILE CREATION MASK, esta mscara est definida no formato dcimal acima descrito, nesta mscara devem estar activos os bits que se pretende forar a zero nos novos ficheiros e directrios. Os utilizadores podem alterar a sua mascara de criao de ficheiros, geralmente o valor inicial (definido pelo sistema) 022, que significa no dar permisso de escrita para o grupo nem para os outros. O valor desta mscara pode ser alterado usando o comando "umask". Alguns sistema Unix podem guardar mascaras individuais para cada utilizador (usando o campo de comentrios do /etc/passwd), a maioria dos sistema Linux no o faz e por isso as alteraes da mascara tm efeito apenas durante a sesso. Quando um utilizador possui direitos de execuo sobre um ficheiro, tal significa que se trata de um programa que pode ser transformado num processo em execuo. Quando um utilizador transforma um destes ficheiros num processo (invoca o executvel) o processo possui sobre o sistema as mesmas permisses do utilizador que o invocou, isso acontece porque os processos ficam com um UID/GID associado correspondentes ao utilizador que os cria. Em muitas situaes torna-se conveniente dar aos utilizadores permisses especiais, mas apenas para executar determinadas tarefas bem definidas que no comprometam a segurana. Para o conseguir, em Unix, possvel associar a um ficheiro executvel o modo SETUID ou SETGID, se o ficheiro executvel possi um destes modos, o processo fica autorizado a alterar respectivamente o seu UID ou GID para os correspondentes aos do ficheiro. Observe-se os exemplos seguintes:
-rwsr-xr-x -r-sr-sr-x 1 root 1 root shadow root 34936 Sep 12 20704 Sep 12 1998 /usr/bin/passwd 1998 /usr/bin/lpr

Podemos observar que o programa /usr/bin/passwd tem activo o modo "s" nas permisses de proprietrio, logo tem a possibilidade de adquirir o UID de root, e as suas permisses, diz-se que um programa SETUID ROOT. Na segunda linha est listado o programa /usr/bin/lpr que SETUID ROOT e SETGID ROOT. Os programas SETUID devem ser vistos sempre com desconfiana pois permitem a um utilizador qualquer adquirir as permisses do proprietrio. Estas permisses especiais apenas devem ser associadas a programas de inteira confiana e muito bem testados, se eventualmente um utilizador conseguir alterar o comportamento normal de um destes programas as consequencias podem ser extremamente graves. Como medida de segurana adicional, em alguns sistemas, os bits SETUID e SETGID podem ser automaticamente desactivados sempre que se realiza uma operao de escrita sobre o ficheiro. Finalmente falta referir a utilizao do bit STICKY (representado pela letra "t"), este bit pode ter diferentes significados em diferentes sistemas Unix, por exemplo para directrios o significado mais habitual impedir a remoo de entradas a outros utilizadores alm do proprietrio dessas entradas, neste contexto habitual estr associado aos directrios

temporrios partilhados, nos quais se pretende que todos os utilizadores possam criar novas entradas, mas no se pretende que uns possam remover/alterar as entradas dos outros:
drwxrwxrwt 5 root root 5120 Nov 19 00:01 tmp

Recorde-se que o direito de remover/mover entradas num sistema de ficheiros Unix, no ditado pelas permisses sobre essas entradas, mas sim pelas permisses sobre o directrio onde as entradas se encontram. Uma outra utilizao comum do STICKY bit em ficheiros executveis, para evitar que fiquem bloqueados quando existem processos respectivos em execuo, se o STICKY bit est activo, o ficheiro binrio colocado no dispositivo de SWAP para ser usado de forma privada pelo processo em execuo. Em alguns sistema apenas o administrador pode activar o STICKY bit. Ligaes Simblicas De entre os vrios tipos de entrada num sistema de ficheiros Unix vulgarmente manuseados directamente pelos utilizadores, alm dos ficheiros e directrios, destacam-se ainda as ligaes simblicas. As ligaes simblicas so um conceito simples, mas com enorme utilizade para os utilizadores em geral e muito em especial para o administrador. Trata-se de entradas no sistema de ficheiros que apontam para outra entrada noutro ponto do sistema de ficheiros. Na listagem exemplo do directrio /etc anteriormente apresentada podem observar-se 3 ligaes simblicas. Para todos os efeitos as propriedadas de uma ligao simblica so as propriedades do "apontado", tipo de entrada (ficheiro, directrio, etc), modo (permisses, etc), UID/GID. A nica diferena entre o apontador (ligao simblica) e o apontado est no nome, que pode ou no ser igual, e na localizao. Para criar uma ligao simblica pode ser usado o comando:

ln -s {apontado(entrada j existente)} {apontador(ligao simblica a criar)}


As utilizaes so as mais diversas. De um modo geral as ligaes simblicas so teis sempre que pretendemos que algo aparente existir onde no existe ou/e que algo aparente ter um nome que no tem.

Administrao de "Software"
A instalao de "software" num sistema Unix pode ser realizada por diversas vias, uma das caracteristicas importantes deste tipo de sistema a possibilidade de as actividades da administrao seram realizadas a diversos nveis de acordo com as necessidades particulares e nvel de conhecimento do administrador sobre os detalhes de funcionamento considerados de baixo nvel.

Gestores de aplicaes instaladas Com o progressivo desenvolvimento do sistema operativo Linux comeam a ser cada vez mais comum "software" de gesto de aplicaes instaladas. Estes programas de gesto do "software" instalado mantm uma base de dados onde so registados todos os programas que esto instalados no sistema, os ficheiros pelos quais cada um dos programas composto e ainda as relaes de dependendecia entre o diverso "software". A sua utilizao extremamente vantajosa e simplifica de forma muito significativa o trabalho do administrador. Remover, actualizar e instalar "software" torna-se muito mais simples. A instalao de um dado "software" com estes sistemas exige desde logo a obteno de um ficheiro de instalao do "software" apropriado ao gestor em uso. Estes ficheiros de instalao (normalmente designados por "packages"), alm dos ficheiros pelos quais constituida a aplicao, contm diversa informao quanto a pr-requesitos a serem verificados, tais como o tipo de plataforma exigido e as dependencias que definem que outros "packages" devem estr previamente instalados no sistema. As dependncias so tambm importantes no que se refere remoo ou actualizao de "software" j que este tipo de operao pode ter consequencias sobre outro "software" instalado que dependente do primeiro. O sucesso deste tipo de gestores depende em larga medida da sua aceitao geral. Um dos mais conhecidos o RPM ("Red Hat Package Manager"), incluido em muitas distribuies Linux tais como "Red Hat" ,"Suse", "Mandrake", ... . Infelizmente, nem sempre se encontram disponveis os "packages" que pretendemos, para a nossa plataforma, para facilitar esta tarefa, o RPM pode usar "packages" em formato "source", ou seja "software" sob a forma de cdigo fonte, sem compilar, o RPM pode depois ser usado para proceder compilao do cdigo fonte, produzindo um "package" binrio pronto a instalar. Os "packages" em formato de cdigo fonte, no caso do RPM so habitualmente conhecidos por SRC-RPM e a sua grande vantagem poderem ser usados em qualquer plataforma, constituindo-se como alternativa quando no existe uma verso RPM (pr-compilada) disponvel para uma dada plataforma, o seu inconveniente que para efectuar a compilao (BUILD) geralmente necessrio instalar "software" adicional que no necessrio para usar as verses pr-compiladas. Software Comercial A maioria do software comercial, por razes obvias, fornecido sob a forma pr-compilada e geralmente no utilizam os gestores de "software" existentes, em seu lugar disponibilizam um programa de instalao que se encarrega de verificar se a plataforma obdece aos requesitos pr-estabelecidos, estas verificaes tentam determinar, por observao do sistema de ficheiros e realizao de diversos testes se os pr-requesitos so atingidos. Algum deste "software" pr-compilado, de menor qualidade, pode mesmo no realizar verificaes, deixando estas a cargo do administrador. Em certos casos, a instalao pode

mesmo ser manual, obrigando o administrador a copiar os ficheiros da aplicao para os locais indicados. A utilizao destes programas de instalao tem o inconveniente, na maioria dos casos, de no actualizar a base de dados do gestor de "software", logo para o gestor esse "software" no existe no sistema, como consequencia a remoo ou actualizao de programas do qual este "software" comercial depende vai ser permitida. Software em cdigo fonte A maioria do "software" "open-source" encontra-se disponvel sob a forma de cdigo fonte simples, geralmente sob a forma de um arquivo em formato TAR, este arquivo contm um directrio base dentro do qual se encontra uma rvore de directrios contendo as vrias partes do cdigo fonte. O "software" distribudo desta forma, pode em principio, ser instalado em qualquer tipo de sistema Unix, contudo trata-se de um processo um pouco mais moroso que envolve a compilao do cdigo fonte. Depois de extraidos os ficheiros do arquivo (para arquivos simples, com extenso [.tar] pode ser usado o comando tar xf, para arquivos comprimidos usando o gzip, geralmente com extensao [.tgz] ou [.tag.gz], necessria a opo z) obtem-se um directrio de base no qual deve existir um programa de configurao, geralmente com o nome "configure". O programa de configurao destina-se a verificar requesitos do sistema e adaptar o cdigo fonte s particularidades do sistema, uma vez executado com sucesso, o "software" encontra-se pronto a ser compilado. O processo de compilao inicia-se com o comando "make" e pode ser algo moroso. Uma vez concluida a compilao com sucesso, geralmente suportada o comando "make install" que vai copiar os ficheiros binrios e outros para os locais apropriados e desta forma instalar a aplicao. Embora o processo descrito acima seja quase "standard", nunca deve ser iniciado sem antes ler a documentao que acompanha o cdigo fonte (geralmente ficheiros README ou INSTALL no interior do directrio de base). Instalao manual de "software" Embora a instalao manual de "software" no seja actualmente muito conveniente, o conhecimento dos procedimentos envolvidos muito importante porque permite ao administrador resolver problemas resultantes de instalaes deficientes. Em Unix para a instalao de aplicaes usado um conjunto de nomes de directrio "standard" que obrigatrio conhecer, cada um destes directrios tem uma finalidade a respeitar:

bin - destina-se a armazenar ficheiros executveis (transformveis em processos) por todos os utilizadores.

sbin - destina-se a armazenar ficheiros executveis (transformveis em processos), mas no se pretende que sejam usados vulgarmente pelos utilizadores, destinam-se ao administrador e ao sistema. lib - contm bibliotecas dinmicas que so carregadas pelos programas de acordo com as suas necessidades. Tambm pode ser usado para guardar ficheiros de configurao e mesmo de dados. etc - contm ficheiros de configurao das aplicaes. var - contm ficheiros de dados das aplicaes. man - contm manuais de utilizao e configurao das aplicaes, em formato apropriado ao programa man. info - contm manuais de utilizao e configurao das aplicaes, em formato apropriado ao programa info.

Este conjunto de directrios (ou parte deles) pode existir em vrios pontos do sistema de ficheiros, esses pontos so o directrio de base de instalao da aplicao, a instalao consiste basicamente na cpia de ficheiros para os subdirectrios apropriados do directrio base:

/ (raiz) - os directrios da raiz so usados pelo "software" de base do sistema, as aplicaes instaladas posteriormente no utilizam normalmente estes directrios, as excepes so os directrios /etc e /var que so usados por algumas aplicaes para armazenar resepectivamente ficheiros de configurao e ficheiros de dados. /usr - este directrio muito utilizado como base de instalao para muitas aplicaes, sendo por isso os respectivos executveis colocados em /usr/bin e as bibliotecas em /usr/lib, os ficheiros de configurao deveriam ser colocados em /usr/etc, mas isso nem sempre acontece e por vezes usado o directrio /etc, o mesmo se passando para os dados relativamente ao directrio var. /usr/local - esta outra base de instalao muito usada, aplicando-se tambm o que foi dito para o directrio de base /usr. Directrios exclusivos - uma aplicao tambm pode ser instalada num directrio de base prprio, criado exclusivamente para a aplicao. Os locais mais habituais para estes directrios serem criados so /opt /usr/local e /usr/lib.

Muitas aplicaes tambm criam ficheiros de configurao/dados nos directrios dos utilizadores, quando estes usam as aplicaes pela primeira vez, isto permite uma personalizao da configurao individual para cada utilizador. A aplicao, uma vez instalada num dado directrio base vai usar esse directrio como base para encontrar os ficheiros de que necessita, nomeadamente de dados e de configurao. Se a aplicao sabe desde logo onde procurar os seus ficheiros, o mesmo no se pode dizer do sistema operativo. Neste aspecto existem 3 situaes onde a interaco entre a aplicao e o sistema operativo pode ser afectada:

Pesquisa de ficheiros executveis Para criar um novo programa em execuo necessrio criar um novo processo (fork) e de seguida usar uma funo "exec" para substituir o nove processo por um

ficheiro binrio. Para usar a funo "exec", ou especificado o caminho completo at ao ficheiro binrio, ou ento usa-se uma das funes "exec" que pesquisam a varivel de ambiente PATH (exec?p). Este processo normalmente levado a cabo pela "shell" do utilizador. Quando um comando invocado normalmente pesquisada a varivel PATH que contm uma sequncia de directrios onde se pode encontrar ficheiros binrios, um habitual para esta varivel "/bin:/usr/bin:/usr/X11R6/bin:/usr/local/bin". O contedo desta varivel pode ser facilmente alterado pelo administrador atravs dos ficheiros /etc/profile, para a "shell" normal (sh/bash) e dos ficheiros /etc/csh.cshrc e /etc/csh.login, para a csh/tcsh. Deste modo quando se instala um novo programa, cujo executvel no se encontra nos directrios habituais da varivel PATH, basta editar estes ficheiros de configurao para adicionar o novo directrio, onde se encontra o ficheiro executvel, por exemplo "/usr/local/netscape/". O problema que as variaveis de ambiente podem ser alteradas pelo utilizador, por outro lado a varivel PATH tende a crescer rpidamente com o aumento das aplicaes instaladas. Uma alternativa, vivel quando o directrio contm um nmero reduzido de executveis criar uma ligao simblica num directrio que est na PATH, por exemplo "ln -s /usr/local/netscape/netscape /usr/local/bin/netscape".

Carregamento de bibliotecas ligadas dinamicamente A maioria dos programas compilados so incompletos, durante a operao de compilao a insero de cdigo contido em bibliotecas (linking) no realizada, em seu lugar a, durante a execuo do programa, as bibliotecas so carregadas em memria e usadas pelo programa. Este processo conhecido por "dynamic linking" e usado intensivamente nos sistemas operativos modernos como o MS-Windows, com as DLL, ou o Linux com as bibliotecas partilhadas ("Shared Libraries"), as bibliotecas partilhadas devem estr disponveis para os programas quando estes so executados. O programa "ldd" permite saber a que bibliotecas est dinamicamente ligado um dado executvel ligado, no exemplo seguinte pode ver-se o resultado dessa verificao sobre o executvel /usr/local/netscape/netscape num dado sistema:
ldd /usr/local/netscape/netscape libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x4000c000) libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x4004e000) libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x40057000) libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x4006c000) libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4 (0x4007e000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4008c000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40097000) libdl.so.1 => /lib/libdl.so.1 (0x40137000) libc.so.5 => /lib/libc.so.5 (0x4013a000) libg++.so.27 => /usr/lib/libg++.so.27 (0x401f6000) libstdc++.so.27 => /usr/lib/libstdc++.so.27 (0x4022e000) libm.so.5 => /lib/libm.so.5 (0x4025f000)

Do lado esquerdo pode observar-se os nomes das bibliotecas de que o programa necessita e do lado direito, onde foram encontradas no sistema de ficheiros. Como se pode observar os nomes destas bibliotecas so geralmente da forma [libNOME.so.NUMERO] quando usado, o nmero indica a verso da biblioteca. Por exemplo a biblioteca X11 encontra-se no directrio /usr/X11R6/lib:
-rw-r--r-1 root root 1085674 Jan /usr/X11R6/lib/libX11.a lrwxrwxrwx 1 root root 13 Nov /usr/X11R6/lib/libX11.so -> libX11.so.6.1 lrwxrwxrwx 1 root root 13 Feb /usr/X11R6/lib/libX11.so.6 -> libX11.so.6.1 -rwxr-xr-x 1 root root 663320 Jan /usr/X11R6/lib/libX11.so.6.1 31 2001

30 15:43 22 31 2001 2001

No caso podemos observar a existncia de 4 entradas com a designao libX11, a entrada com extenso .a destina-se a ser usada durante a compilao de programas ("static linking"), no final encontra-se a verso partilhada que ser carregada pelo "netscape", embora o netscape deseje a verso 6, vai receber a verso 6.1, isso conseguido usando uma ligao simblica. As bibliotecas possuem normalmente dois nmeros de verso, o primeiro ("major") o mais significativo, sendo mantida a compatibilidade dentro de todas as sub-verses, por isso os programas so normalmente ligados apenas ao nmero de verso mais significativo. A forma como as bibliotecas so procuradas ligeiramente mais complexa do que o que acontece para os executveis, as bibliotecas partilhadas so procuradas na seguinte ordem: 1. Nos directrios definidos na varivel de ambiente LD_LIBRARY_PATH, por razes de segurana obvias (...) para os programas SETUID/SETGID isto ignorado. 2. Na lista de bibliotecas contida no ficheiro /etc/ld.so.cache 3. No directrio /usr/lib 4. No directrio /lib A lista de bibliotecas definida no ficheiro ld.so.cache no manualmente editvel porque no um ficheiro de texto este ficheiro usado pelo sistema para manter informao sobre as bibliotecas partilhadas que vo sendo usadas de forma a acelerar o processo de carregamento em futuras utilizaes. A actualizao deste ficheiro pode ser forada com o comando "ldconfig". O comando ldconfig procura bibliotecas dinmicas nos seguintes directrios: o o o lista de directrios especificados na linha de comando (opcional) lista de directrios contidos no ficheiro /etc/ld.so.conf (um directrio por linha) directrios /lib e /usr/lib

Alm de actualizar a cache de bibliotecas que acelera o carregamento destas, o ldconfig tambm se encarrega de actualizar/corrigir as ligaes simblicas de acordo com os nmeros de verso disponveis. O programa "ldconfig" deve ser sempre invocado durante o arranque da mquina. Quando se instala um programa que contm bibliotecas partilhadas, estas tero de estar acessiveis para o programa poder funcionar, se a base de instalao o directrio /usr, no existe qualquer problema, igualmente, se a base /usr/local tal no apresenta grande problema porque o directrio /usr/local/lib um dos que est normalmente registado no ficheiro /etc/ld.so.conf, por isso basta executar o comando "ldconfig" para actualizar a "cache". Se o programa se instala num directrio particular, por exemplo /usr/local/kde, a melhor soluo adicionar o directrio que contm as respectivas bibliotecas ao ficheiro /etc/ld.so.conf e de seguida actualizar a "cache" com o comando ldconfig.

Pesquisa de manuais pelos comandos do sistema (ex.: man, info) O comando "man" utiliza procedimentos semelhantes aos usados para as bibliotecas dinmicas, o sistema mantm uma "cache" das localizao das pginas dos manuais usadas recentemente, o comando "mandb" actualiza essa informao em moldes semelhantes aos do comando "ldconfig", a lista de directrios a pesquisar est definida no ficheiro /etc/man_db.config, alm disso o comando "man" tambm procura os manuais nos directrios definidos na varivel de ambiente "MANPATH". O comando "manpath" pode ser usado pelos utilizadores para definir a varivel PATH de acordo com a informao existente no ficheiro /etc/man_db.conf. O comando "info" (e tambm o emacs) utiliza as variveis de ambiente INFOPATH e INFODIR para procurar os documentos tipo "info", normalmente estas variveis devem conter "/usr/info:/usr/local/info". Para estes documentos no existe "cache", quando um programa no tem como base de instalao /usr ou /usr/local pode ser necessrio adicionar o novo directrio s variveis de ambiente, para isso ser necessrio editar os ficheiros /etc/profile e /etc/csh.cshrc.

Administrao de Servios
Os servios de um sistema so um conjunto de meios que permitem um acesso organizado aos recursos, a maioria dos servios destinam-se a acesso externo (via rede) o acesso interno (apartir da "shell") muito mais directo e simples (acesso ao sistema de ficheiros, execuo de comandos, ...) pelo que normalmente no necessrio recorrer a este conceito. Um servio de rede, que pretende facultar acesso a determinados recursos partindo do exterior do sistema tem de se preocupar com vrias questes, tais como tipo de protocolo de comunicao usado, autenticao de utilizadores e filtragem de origens dos pedidos.

Os servios de rede usam protocolos de rede para transporte de dados, em Unix os protocolos de eleio so o TCP e o UDP que por sua vez usam o IP ("Internet Protocol"), mas especialmente quando se fala de Linux existe um grande nmero de protocolos suportados, tais como o IPX ou o Appletalk. Os servios locais utilizam mecanismos internos de comunicao (IPC) tais como "Sockets Unix", "Filas de Mensagens", "Pipes" (FIFOs) e memria partilhada. Embora o Unix, e em particular o Linux, suportem outros protocolos de rede/transporte, existe uma clara ligao entre o Unix e a pilha TCP/IP, tal deve-se ao facto de o Unix ter sido a plataforma usada para o desenvolvimento do TPC/IP. Por sua vez o TCP/IP foi sempre a pilha mais usada pelo Unix, muitas implementaes Unix apenas suportam TCP/IP e praticamente todos os sistemas operativos Unix suportam TCP/IP. Os servios so quase todos implementados segundo o modelo "Cliente-Servidor", neste modelo o servidor uma aplicao passiva que aguarda o contacto de um cliente, quando tal acontece "acorda" e presta o servio pedido. O suporte de multiplas comunicaes independentes com processos no interior de uma dada mquina assegurado atravs da multiplexagem da interface-de-rede/endereo-de-mquina atravs dos nmeros de porto ou porta ("port number"). Consultar o documento Redes, endereos, nomes e servios - introduo. Na pilha TCP/IP existem dois protocolos disponveis para a implementao de servios, o UDP e o TCP:

UDP - O "User Datagram Protocol" um protocolo sem ligao que se destina troca de blocos isolados de informao, um protocolo no fivel, isto no se garante que os dados chegam ao destino e s em algumas situaes que o emissor tem conhecimento de que os dados no chegaram ao destino. Dadas estas caracteristicas o UDP apenas adquado a servios simples, sem sesso/ligao, com volumes muito reduzidos de dados e sem grandes exigencias de fiabilidade. TCP - O "Transmission Control Protocol" um protocolo fivel com controlo de fluxo e erros, com ligao, uma vez estabelecida a ligao as comunicaes entre os dois processos envolvidos funcionam sobre um canal lgico dedicado, no acessvel a outros processos. O TCP o protocolo escolhido sempre que o servio implica a definio de uma sesso/ligao. Mesmo que o servio no implique o estabelecimento de ligao/sesso, se os volumes de dados so elevados o UDP coloca dificuldades e dever optar-se pelo TCP.

Uma das caracteristicas que um servio deve ter estar permanentemente disponvel, independentemente do nmero de clientes que estao a ser atendidos. A implementao das aplicaes servidoras tem de atender a este aspecto e s caracteristicas do protocolo usado:

Servidores UDP - para cada porta de destino (servio), com o protocolo UDP apenas possvel distinguir um processo servidor de destino no interior da mquina, isso significa que um nico processo servidor vai ter de atender todos os clientes. Este facto introduz limitaes no servio porque o servidor dever ser do tipo sem-

estado ("stateless"), ou seja cada pedido deve ser autonomo e no depender de outros pedidos anteriores. Esta limitao muito importante porque para usar UDP com servios onde existe o conceito de sesso essa funcionalidade ter de ser totalmente implementada nas aplicaes servidora e cliente e o servidor torna-se extremamente complexo porque tem de manter multiplas sesses de diversos clientes num nico processo. Mais importante ainda esta limitao dificulta a transferncia de grandes quantidades de dados, se a quantidade de dados superior permitida para um "datagrama" UDP, tero de ser usados vrios "datagramas", mas estes tero de constituir pedidos totalmente independentes. A disponibilidade permanente do servio aparente, enquanto o servidor est a atender um cliente, outros pedidos, de outros clientes so armazenados em fila de espera ("buffer"), quando o servidor acaba de processar um pedido l o seguinte do "buffer". Por estas razes o UDP apenas normalmente usado para servios muito simples que consistem no envio de apenas um pedido e recepo de uma resposta, ambos de reduzida dimenso. Um exemplo no tpico o servio TFTP ("Trivial File Transfer Protocol") que um servio de acesso a ficheiros, normalmente em modo de leituraapenas que muito usado para o arranque de postos de trabalho sem disco. O TFTP usa o protocolo UDP, para o conseguir, os ficheiros so divididos em blocos 512 bytes (para "caberem" num "datagrama" UDP), o cliente envia pedidos isolados ao servidor contendo o nome do ficheiro e nmero do bloco pretendido, todo o controlo fica a cargo do cliente, por exemplo se um bloco no recebido o cliente ter de efectuar novamente o pedido.

Servidores TCP - o protocolo TCP muito mais elaborado, com o TCP possvel distinguir vrios processos servidores de destino no interior da mquina, essa distino baseia-se no porto/endereo-de-origem dos dados. Quando um processo servidor TCP recebe um pedido de ligao de um cliente gera-se um novo descritor que representa a ligao estabelecida, neste descritor todos os dados recebidos vem do cliente ligado e todos os dados emitidos sero recebidos apenas pelo cliente ligado, esta caracteristica permite definir este protocolo como sendo do tipo "comligao", os dados no so enviados em blocos como no UDP, mas sim em fluxo contnuo. Alm deste aspecto o TCP fivel porque implementa mecanismos de controlo de fluxo e erros baseado no protocolo de janela deslizante orientado a caractere. Estas caracteristicas do protocolo TCP tornam muito simples a implementao de servios com sesso, quando o processo servidor recebe um pedido de ligao gerase um novo descritor ligado ao novo cliente, neste momento o servidor cria um novo processo ("fork") que usa apenas o novo descritor para atender em exclusivo o novo cliente, o processo pai continua a atender pedidos de ligao. O tempo de indisponibilidade do servio muito menor, limitando-se ao tempo necessrio para criar um novo processo.

Em TCP a questo da quantidade de dados a transferir no se coloca porque os dados so transmitidos em fluxo continuo, sem qualquer espcie de limitao. Podemos ento considerar dois tipos de servidor bsico, os servidores UPD asseguram servios simples sem ligao, so constituidos por um nico processo que atende todos os pedidos de todos os clientes, quando existe um grande nmero de clientes, o tempo de resposta afectado segundo o modelo das filas de espera M/D/1. Os servidores TCP proporcionam servios fiveis, com ligao, o servidor TCP constituido por um processo que recebe os pedidos de ligao dos clientes, quando recebe um pedido cria um novo processo que trabalha em exclusivo para o novo cliente, os tempos de resposta sob presso de um grande nmero clientes no so significativos porque existem processos servidores dedicados a cada cliente. Para servios simples, os servidores UDP so mais eficientes em tempo de resposta porque no necessitam de criar um novo processo. Os sistemas tipo Unix so adequados a muitas finalidade, mas a sua eficincia e fiabilidade tornaram-nos a primeira escolha como plataforma para a implementao de servios. Os servios devem estr disponveis imediatamente depois do arranque do sistema, os processos servidores so criados apartir dos "scripts" de boot de sistema, de acordo como o que est definido no ficheiro /etc/inittab, geralmente estes "scripts" encontram-se dentro do directrio /sbin/init.d/, o exemplo seguinte mostra parte do ficheiro /sbin/init.d/apache :
case "$1" in start) if test -x /usr/sbin/httpd ; then echo "Starting WWW-Server apache." /usr/sbin/httpd -f /etc/httpd/httpd.conf fi ;; stop) if [ -f /var/run/httpd.pid ] ; then echo -n "Shutting down Apache HTTP server" kill `cat /var/run/httpd.pid` rm -f /var/run/httpd.pid else echo -n "Apache not running?" fi echo ;; restart) if [ -f /var/run/httpd.pid ] ; then echo -n "Reload Apache configuration" kill -1 `cat /var/run/httpd.pid` else echo -n "Apache not running?" fi echo ;; *) echo "Usage: $0 {start|stop|restart}" exit 1

esac

Este script automaticamente executado durante o arranque do sistema, com o argumento "start", pode observar-se que o processo servidor criado por invocao do binrio /usr/sbin/httpd que trata de criar o processo servidor. O "Internet Super-Server" (inetd) comum um sistema Unix prestar dezenas ou centenas de servios distintos, em principio seria necessrio ter em execuo outros tantos processos servidores. Embora um processo servidor no apresente grande consumo de capacidade de processamento quando no est a atender clientes, usa alguma memria central, e mesmo que tal no seja muito significativo pode considerar-se um despedicio de recursos porque so processos que at existir algum cliente "no fazem nada". O "Internet Super-Server" (inetd) resolve esta situao, a ideia ter um nico processo que assegure o atendimento de todos os diversos tipos de servio necessrios no sistema. claro que o "inetd" no possui as funcionalidades dos diversos tipos de servio, para isso recorre a programas externos. O "inetd" limita-se a escutar as vrias portas de servio, quando chega um pedido "passa a batata quente" a um programa externo especfico para esse servio. O programa "inetd" consulta o ficheiro de configurao /etc/inetd.conf, neste ficheiro encontram-se definidos os servios que devem ser assegurados pelo "inetd", um servio por linha, cada linha contm os seguintes campos separados por espaos:

Nome do servio - representa na realidade o nmero de porto, o "Nome de servio" deve estar definido no ficheiro /etc/services. Tipo de servio - define o tipo de servio, este valor est directamente relacionado com o protocolo e corresponde aos valores estabelecidos para a "system-call" "socket". Os valores mais usados so "stream" para servios TCP com ligao ou o valor "dgram" para o servio de "datagramas" UDP. Protocolo - trata-se da designao do protocolo usado, estes nomes esto registados no ficheiro /etc/protocols, os valores mais usados so "tcp" e "udp". Modo - este campo pode ter os valores "wait" ou "nowait", est relacionado com o funcionamento interno do "inetd" que ser abordado a seguir. Nome de Utilizador - identifica o nome do utilizador com que o servio ser prestado (executado), normalmente "root", mas para servios que no necessitam de acessos especiais ao sistema pode ser usado um nome de utilizador sem direitos especiais tal como "nobody". O nome de utilizador pode ser seguido de um nome de grupo (separado por um ponto). Programa servidor e argumentos - trata-se do nome do programa que o "inetd" invocar para prestar o servio, este campo constiuido por uma sequncia de argumentos em formato apropriado para a funo "execl", ou seja o nome do executvel com o caminho completo at ele, novamente o nome do executvel, e depois os argumentos.

O exemplo seguinte apresenta um extracto de um ficheiro /etc/inetd.conf:


echo daytime time ftp dgram udp wait root internal dgram udp wait root internal stream tcp nowait root internal stream tcp nowait root /usr/sbin/tcpd in.ftpd telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd smtp stream tcp nowait root /usr/sbin/sendmail sendmail -bs shell stream tcp nowait root /usr/sbin/tcpd in.rshd -L pop3 stream tcp nowait root /usr/sbin/popper popper -s tftp dgram udp wait.400 root /usr/sbin/tcpd in.tftpd /tftpboot bootps dgram udp wait root /usr/sbin/bootpd bootpd -d4 -c /usr/local2/tftpboot finger stream tcp nowait nobody /usr/local/libexec/in.xfingerd in.xfingerd -b dc=pt systat stream tcp nowait nobody /bin/ps -auwwx netstat stream tcp nowait root /bin/netstat netstat -a netbios-ssn /etc/smb.conf netbios-ns # End. stream tcp dgram udp nowait root wait root /usr/sbin/smbd /usr/sbin/nmbd

ps

smbd -s nmbd

O "inetd" assegura alguns servios bsicos sem recurso a programas externos, nesses casos (3 primeiras linhas do exemplo) usa-se a palavra "internal" em lugar do nome do executvel externo. O programa "tcpd" um auxiliar que realiza algumas validaes da proveniencia dos pedidos e ser abordado adiante. O funcionamento do "inetd" pode ser descrito do seguinte modo: 1. O ficheiro de configurao /etc/inetd.conf lido, o ficheiro lido novamente sempre que o processo "inetd" recebe o sinal "HUP". 2. So abertos os "sockets" apropriados a cada servio e associados ao respectivo nmero de porto. 3. utilizada a "system-call" "select" para saber se chegou um "datagrama" (dgram/udp) ou um pedido de ligao (stream/tcp) em qualquer dos portos de servio. 4. Quando chegam dados, criado um novo processo, no novo processo: 1. o UID/GID alterado para corresponder ao que est definido para esse servio. 2. os descritores "standard" de entrada e sada de dados so fechados (close(0);close(1);) e o "socket" duplicado (dup2) para esses descritores. 3. usada a funo "execl" para substitui o processo pelo executvel, tal como est especificado para esse servio.

5. No processo original (inetd) a "system-call" "select" novamente invocada para detectar novos pedidos nos "sockets". Se o servio est definido como sendo em modo "nowait", ento o "socket" correspondente ao servio tambm vai ser monitorizado, se o modo "wait" o "socket" fica suspenso e no monitorizado. Neste ltimo caso o "socket" s volta a ser monitorizado quando o processo que foi criado para atender o pedido anterior terminar. Os servios com ligao (stream/tcp) podem ser sempre do tipo "nowait" porque para cada cliente criado um "socket" independente ("system-call" "accept"), assim o "inetd" pode atender imediatamente novos pedidos para esse servio. Pelo contrrio, para os servios sem ligao dever ser sempre usado o modo "wait" porque s existe um "socket" e consequentemente no podem existir dois processo a usa-lo, apenas quando o novo processo termina possvel o "inetd" voltar a receber pedidos desse servio. Por esta razo os servidores UDP devem ter tempos de execuo o mais curtos possveis, alm disso se um destes servidores "encrava", o servio fica bloqueado. Imediatamente a seguir ao modo wait/nowait pode ser colocado um nmero, separado por um ponto que indica o nmero mximo de processos que podem ser criados por minuto para atender o servio, se nada for indicado o valor usado pelo "inetd" normalmente de 40. Os servidores executveis, invocados pelo "inetd" para prestar os servios utilizam a entrada "standard" para receber dados do cliente (STDIN/Descritor 0) e a sada "standard" para enviar dados ao cliente (STDOUT/Descritor 1). Isto significa que os servidores invocados pelo "inetd" no necessitam de ser aplicaes especificamente desenvolvidas para trabalhar em rede, no exemplo acima pode observar-se que as linhas correspondentes aos servios "systat" e "netstat" utilizam comandos habitualmente usados na "shell", por exemplo, quando o comando "ps" invocado escreve o seu resultado no descritor 1, como o "inetd" duplicou o descritor do "sochet" de rede para o descritor 1, o resultado enviado ao cliente, no caso atravs de um "datagrama" UDP. O "xinetd" uma verso melhorada do "inetd", utiliza o ficheiro de configurao /etc/xinetd.conf, mas pode ser realizada a incluso de outros ficheiros de configurao, geralmente usa-se um directrio /etc/xinetd.d/ para esse efeito, o "xinetd" semelhante ao "inetd", o formato dos ficheiros de configurao diferente, mas o contedo essencialmente o mesmo, ao contrrio do "inetd", o "xinetd" permite filtrar os endereos de origem dos pedidos, para se conseguir isso com o "inetd" necessrio recorrer a um programa auxiliar, o "tcpd". Os sistemas Linux possuem uma biblioteca para implementao de filtragem de pedidos, essa biblioteca "libwrap.a" ("Access Control Library) define funes para realizar diversos tipos de validao, a validao (para cada servio) pode basear-se em "nome do cliente", "endereo do cliente", "nome do utilizador", "nome do processo servidor", "nome do servidor", "endereo do servidor" e utiliza dois ficheiros de configurao: /etc/hosts.allow e /etc/hosts.deny. Estes ficheiros usam mascaras para identificar os clientes. Primeiro verificado se o cliente se ajusta a alguma definio no /etc/hosts.allow, se isso acontecer o

acesso imediatamente autorizado. Se no, ento ser verificado se o cliente est abrangido pelo /etc/hosts.deny, se isso acontece o acesso negado, caso contrrio autorizado. O programa "tcpd" ("TCP/IP Daemon Wrapper Program") destina-se a servir de intermedirio entre o "inetd" e servidores que no suportam esta biblioteca de controlo de acesso. O "inetd" invoca o "tcpd" em lugar do servidor, o "tcpd" determina o nmero de porto/servio a que esto associados os descritores (0/1) ("system-call" "getsockname") e valida o acesso usando a "libwrap", se o acesso vlido utiliza uma funo "exec" para se substituir pelo verdadeiro servidor. Como se pode observar no exemplo anterior, o "tcpd" no necessita de uma especificao do executvel servidor ao estilo funo "exec", basta o nome do executvel e os respectivos argumentos, o "tcpd" permite que o nome do executvel seja especificado sem caminho, nesse caso o executvel ser procurado num directrio pr-definido, normalmente /usr/bin/. Em termos de validao de acessos, a utilizao do "xinetd" vantajosa porque apesar de no ter tantas possibilidades de configurao como a "libwrap" usada pelo "tcpd" garante uma negao de acesso mais directa. A combinao "inetd/tcpd" obriga a criar um novo processo mesmo que depois o cliente no seja autorizado. Isso pode facilitar ataques de negao de servio (saturao de pedidos). Confiana entre sistemas Unix A relao de confiana entre certos servidores um conceito actualmente suportado por quase todos os sistemas operativos com pretenes a servirem de plataforma a servidores. Estas relaes de confiana, geralmente definidas entre sistemas com administrao comum visam aumentar a cooperao entre servidores, permitindo uma melhor distribuo dos servios e facilitando a administrao. No limite o conjunto de servidores cooperantes pode funcionar como um todo e apresentar neste ponto de vista capacidade impossveis de atingir com um nico sistema. A cooperao entre sistemas envolve a existncia de comunicaes entre eles, na maioria dos casos sob a forma de prestao de servios, o problema que grande parte destes servios so sensiveis sob o ponto de vista de segurana e por isso necessrio utilizar mecanismos de autenticao que tornam as operaes mais pesadas. Os sistemas Unix utilizam um mecanismo muito simples que dispensa a utilizao de processos pesados de autenticao, este mecanismo baseia-se apenas nos protocolos de comunicao e aproveita o facto de apenas o administrador poder usar portos UDP/TCP com valores inferiores a 1024, conhecidos normalmente por "portos reservados". No sistema que presta o servio (servidor) definem-se estaticamente, os endereos de rede (IP) dos clientes de confiana, quando o servidor recebe um pedido consulta esta informao e compara o endereo de origem para saber se o cliente de confiana. Em sistemas multi-utilizador esta verificao insuficiente, necessrio saber se foi o utilizador "root" que emitiu o pedido, para isso o cliente tem de usar um porto inferior a 1024, assim o servidor alm de verificar se o endereo de origem corresponde a uma mquina de confiana tem tambm de verificar se o porto de origem inferior a 1024,

nessas condio o servidor sabe que o pedido provm do utilizador "root" na "mquina de confiana". Por ser extremamente simples este mecanismo muito eficinte, mas baseia toda a validao no endereo de origem o que pode no ser totalmente seguro. Este mecanismo usado por vrios servios tais como "Remote Shell/Remote Copy" (rcp/rsh/rshd), "Remote Login" (rlogin/rlogind) e "Line Printer" (lpr/.../lpd), todos estes servidores usam o ficheiro de configurao /etc/hosts.equiv onde se encontram definidos os nomes/endereos dos "clientes de confiana". Muitos destes comandos destinam-se a ser invocados directamente pelo utilizidor, para conseguirem abrir um porto reservado (<1024) so SETUID "root". Uma outra aplicao importante do conceito de "sistema de confiana" no NFS ("Network File System"), este sistema de servidores de ficheiros foi desenvolvido especificamente no contexto Unix e radicalmente diferente dos outros servidores de ficheiros mais comuns. Enquanto os servidores de ficheiros mais conhecidos como Windows (SMB) e NetWare (NCP) baseiam este tipo de servio no estabelecimento prvio de uma sesso de utilizador (geralmente autenticada por "username/password"), os servidores NFS disponibilizam ficheiros a mquinas clientes e no a utilizadores em particular. A configurao de um servidor NFS (mountd/nfsd) baseia-se no ficheiro /etc/exports, neste ficheiro so definidos os directrios a exportar (sub-directrios automaticamente incluidos) e uma lista de clientes (mquinas/endereos) que podem usar cada um dos directrios, para este efeito os clientes refernciados aqui so considerados de confiana. Para cada cliente possvel ainda especificar diversas opes relativas ao modo como o directrio exportado, o extracto seguinte apresenta um ficheiro /etc/exports:
# This file contains a list of all directories exported to other computers. # It is used by rpc.nfsd and rpc.mountd. /tftpboot/192.168.0.1 linuxbox(rw,no_root_squash) /usr/local *(ro) newhost(rw) /cdrom1 *(ro)

Neste exemplo pode observar-se que os directrios /usr/local e /cdrom1 so exportados para todos os clientes (*), em modo de leitura apenas (ro), sendo um acesso apenas de leitura e no sendo a informao confidencial, permite-se deste modo um acesso pblico a estes directorios. O cliente "newhost" tem no entanto acesso de escrita (rw) ao directrio /usr/local. O directrio /tftpboot/192.168.0.1 exportado em modo "read-write" para o cliente "linuxbox", usada ainda a opco "no_root_squash". Os pedidos envidos ao servidor NFS transportam sempre o UID/GID do utilizador que os desencadeou no cliente, no servidor esse UID/GID usado no acesso ao directrio local, por esta razo conveniente que os UID/GID sejam os mesmos no cliente e no servidor, para isso basta centralizar a base de dados de utilizadores, por exemplo recorrendo a um servidor NIS.

A utilizao no servidor NFS do UID na mquina cliente tem uma excepo, por razes de segurana quando o servidor NFS recebe um pedido do UID=0 (root) no usa esse UID no servidor, em seu lugar usa o utilizador "nobody", esta medida de segurana pode ser desactivada usando a opo "no_root_squash", tal como se pode observar no exemplo acima. O operao se alterao de UID entre cliente e servidor conhecida por "squashing" e sendo automtica para o UID=0 pode ser forada para outros UIDs. O servidor NFS apenas aceita pedidos provenientes de portas reservadas (<1024), o cliente NFS est integrado no nclo do sistema operativo da mquina cliente, o acesso ao servidor estabelecido pelo administrador usando o comando "mount", geralmente colocada uma entrada no /etc/fstab para que seja realizado durante o arranque do sistema. Na mquina cliente, a forma como os utilizadores acedem ao sistema de ficheiros de total responsabilidade da administrao local, uma vez montado, o directrio remoto torna-se acessvel localmente como qualquer outro sistema de ficheiros. Uma das grandes vantagens dos servidores NFS que no tm estado ("stateless"), apenas facultam operaes deleitura e escrita, no disponibilizando as operaes de abertura e encerramento do ficheiro, por esta razao se um servidor NFS reinicializado, os clientes no perdem informao, apenas existe uma indisponibilidade temporria. Segurana da confiana baseada em endereos O mecanismo de confiana entre mquinas baseado nos endereos de origem dos pedidos tem a grande vantagem de ser muito ligeiro e logo muito eficinte sob o ponto de vista de performance, contudo a sua aplicao deve ter em considerao que se um intruso conseguir forjar o endereo de uma mquina de confiana, tudo est perdido. Desde logo este mecanismo s deve ser usado sob endereos de rede que so geridos pelo mesmo administrador dos sistemas, geralmente todos pertencentes a uma mesma rede. Embora se trate de forjar o endereo de origem do pedido, o intruso tem tambm de se assegurar que recebe os dados de resposta, isto complica bastante a tarefa, considerando que as mquinas de confiana se encontram todas numa mesma rede local, a menos que o servidor verdadeiro esteja inactivo, impossvel realizar o ataque porque ao existirem duas mquinas com o mesmo endereo torna-se imprevisivel a qual das mquinas vo ser entregues os dados que de qualquer forma no ser legiveis porque so apenas fragmentos. Uma abordagem possvel seria desencadear um ataque duplo, por um lado bloquear o servidor verdadeiro com um ataque de negao de servio (inundao de pedidos) e simultaneamente usar outra mquina para simular o endereo do servidor verdadeiro. O ataque descrito possvel se os servidores usarem ARP dinmico (situao usual). Para fazer os dados chegar ao destino dentro de uma rede local, o endereo IP no suficiente porque a infra-estrutura de comunicao usada (ex: ethernet) usa outro formato de endereos conhecidos por endereos fsicos ou endereos MAC. Assim cada sistema Unix mantm uma tabela de equivalencias entre endereos IP locais e endereos MAC locais que lhe permite fazer chegar os dados ao destino correcto dentro de uma rede local.

Para evitar a definio esttica das tabelas MAC usado um protocolo auxiliar, o ARP ("Address Resolution Protocol") que permite determinar quando necessrio, qual o endereo MAC correspondente a um dado endereo IP. Para evitar o recurso sistemtico a este protocolo, as equivalencias IP/MAC so guardadas numa tabela interna (tabela ARP), quando determinadas via protocolo ARP, as entradas nesta tabala so temporrias e so eliminadas depois de estarem algum tempo sem serem usadas. O problema do protocolo ARP que no tem qualquer segurana, explicado de forma simples funciona do seguinte modo: enviado a todos os ns da rede ("broadcast") um pedido para que o detentor do endereo IP do qual se pretende o MAC responda, ao obter a resposta fica-se a conhecer o endereo MAC. Como obvio qualquer n da rede que diga ser o detentor desse endereo IP vai ser aceite. A alternativa utilizar uma tabela ARP esttica, isso obriga o administrador a inserir com a ajuda do comando "arp" entradas na tabela, inseridas deste modo estas entradas so permanentes e o protocolo ARP nunca ser usado para elas. As tabelas ARP estticas aumentam um pouco a segurana, e inviabilizam a maioria dos ataques, embora afectem o funcionamento do sistema verdadeiro, no ser possvel ao intruso realizar operaes sobre os sistemas aproveitando o estatuto de confiana. Com ARP esttico o intruso obrigado obrigado a simular no apenas o endereo IP, mas tambm o endereo MAC, a maioria das interfaces de rede e respectivos "device drivers" actuais permitem que o endereo MAC seja alterado. Os efeitos da existncia de dois ns com o mesmo endereo MAC numa mesma rede inviabilizam na maioria dos casos a comunicao, os efeitos exactos dependem da infra-estrutura de comunicao, por exemplo se se trata de um meio de "broadcast" simples ou de uma rede com comutao. Na eventualidade de o sistema verdadeiro estar inactivo (sem comunicaes), a tarefa do intruso fica muito facilitada, se for usado ARP dinmico, basta usar na mquina intrusa o mesmo IP do sistema verdadeiro, se for usado ARP esttico ter tambm de ser simulado o endero MAC. Para resolver o problema s existe uma via segura: evitar o acesso fsico rede onde se encontram os servidores. Esta configurao corresponde alis ao modelo mais aconselhado para implementao de "intranets" com ligao "internet". Aconselha-se vivamente que a rede onde se encontram os sistemas servidores esteja isolada e no seja a mesma rede onde os utilizadores trabalham, este tipo de rede isolada, exclusiva para servidores corresponde ao que se designa vulgarmente por rede desmilitarizada (DMZ "DeMilitarized Zone"). A ligao desta rede "internet" e "intranet" assegurada por um ou mais "routers"/"firewalls".

You might also like