![[OpenBSD]](../../images/smalltitle.gif){kind=small}
[Index de la FAQ] [Section 9 - Migrer vers OpenBSD] [Section 11 - Le système X Window]
Les utilisateurs existant sur le système doivent être rajoutés au groupe "wheel" à la main. Ceci est fait pour des raisons de sécurité, et vous devriez apporter une attention toute particulière lorsque vous donnez l'accès à ce groupe à des utilisateurs. Sous OpenBSD, les utilisateurs appartenant au groupe wheel sont autorisés à utiliser le programme su(1) pour devenir root. Les utilisateurs n'appartenant pas au groupe "wheel" ne peuvent pas utiliser su(1). Voici un exemple d'une entrée /etc/group pour mettre l'utilisateur ericj dans le groupe "wheel".
Si vous ajoutez un utilisateur avec adduser(8), vous pouvez le mettre dans le groupe wheel en répondant wheel à la question "Invite user into other groups:". Ceci aura pour effet de rajouter l'entrée correspondante dans /etc/group qui ressemble à la ligne suivante :
wheel:*:0:root,ericj
Si vous cherchez un moyen pour limiter l'accès des utilisateurs aux privilèges du super utilisateur, sans pour autant les mettre dans le groupe "wheel", utilisez sudo(8).
Pour dupliquer votre système de fichiers, utilisez dump(8) et restore(8). Par exemple, pour dupliquer tout ce qu'il y a sous le répertoire SRC vers le répertoire DST, faites un :
# cd /SRC; dump 0f - . | (cd /DST; restore -rf - )
dump est conçu pour vous fournir beaucoup de possibilités de sauvegarde, et c'est peut-être trop si vous voulez juste dupliquer une partie d'un système de fichiers (entier). La commande tar(1) peut être plus rapide pour ce genre d'opération. Le format est très similaire à celui de dump :
# cd /SRC; tar cf - . | (cd /DST; tar xpf - )
OpenBSD utilise un démarrage de type rc(8). Il utilise seulement quelques fichiers clés pour le démarrage.
/etc/rc.conf (ou /etc/rc.conf.local), /etc/rc.local et /etc/rc.shutdown sont les principaux fichiers à connaître par l'administrateur système. Pour comprendre le fonctionnement de la procédure rc(8), en voici le déroulement :
/etc/rc est appelé après le démarrage du noyau :
La plupart des services fournis par défaut avec OpenBSD sont lancés au démarrage simplement en modifiant le fichier de configuration /etc/rc.conf. Pour commencer, jetez un coup d'oeil au fichier /etc/rc.conf par défaut. Vous verrez des lignes similaires à la ligne suivante :
ftpd_flags=NO # for non-inetd use: ftpd_flags="-D"
Une ligne telle que celle-ci montre que ftpd n'est pas lancé au démarrage du système (du moins pas à travers rc(8), lisez la FAQ Serveur FTP Anonyme pour plus d'informations). Dans tous les cas, chaque ligne est dotée d'un commentaire qui vous montrent les drapeaux utilisés dans le cadre d'une utilisation NORMALE du service. Cela ne veut pas dire que vous devez appeler ce service avec ces mêmes drapeaux. Lisez la page man correspondante pour savoir comment démarrer un service donné de la manière que vous souhaitez. Par exemple, voici la ligne par défaut concernant httpd(8) :
httpd_flags=NO # for normal use: "" (or "-DSSL" after reading ssl(8))
D'après cet exemple, vous pouvez voir qu'aucun drapeau n'est nécessaire pour démarrer httpd normalement. Ainsi, la ligne " httpd_flags="" suffit. Mais pour démarrer httpd avec le support ssl (Reportez vous à la FAQ SSL ou à ssl(8) ), vous devez démarrer httpd avec une ligne comme celle-ci : "httpd_flags="- DSSL"".
Une autre approche serait de ne jamais toucher à /etc/rc.conf. Au contraire, créez le fichier /etc/rc.conf.local et ne copiez que les lignes que vous comptez changer dans /etc/rc.conf et modifiez-les comme vous voulez. Ceci peut rendre vos mises à jour futures plus faciles -- tous les changements se trouvant dans un fichier.
Pour les services que vous installez via les paquetages ou d'autres méthodes, vous devez utiliser le fichier /etc/rc.local. Par exemple, j'ai installé un service fourni par l'applicatif /usr/local/sbin/daemonx. Je souhaite que ce service soit lancé au démarrage. Pour cela, je rajoute les lignes suivantes dans /etc/rc.local :
if [ -x /usr/local/sbin/daemonx ]; then
echo -n ' daemonx'; /usr/local/sbin/daemonx
fi
(Si le service ne se détache pas automatiquement lors de son démarrage, souvenez-vous de rajouter "&" à la fin de la commande.)
A partir de là, ce service sera lancé au démarrage. Vous pourrez voir toutes les erreurs au démarrage. Un démarrage normal sans erreurs affichera le message suivant :
Starting local daemons: daemonx.
/etc/rc.shutdown est un script exécuté à l'arrêt de la machine. Toutes les tâches à effectuer avant l'arrêt du système devront être ajoutées à ce fichier. Si vous avez apm, vous pouvez aussi positionner "powerdown=YES". C'est l'équivalent de "shutdown -p".
Essayez ceci :
# grep relay-domains /etc/mail/sendmail.cf
Le résultat ressemblerait à la ligne suivante :
FR-o /etc/mail/relay-domains
Si ce fichier n'existe pas, créez le. Vous devez saisir les hôtes qui envoient des messages à distance en respectant la syntaxe suivante :
.domain.com #Allow relaying for/to any host in domain.com
sub.domain.com #Allow relaying for/to sub.domain.com and any host in that domain
10.2 #Allow relaying from all hosts in the IP net 10.2.*.*
N'oubliez pas d'envoyer un signal 'HangUP' à sendmail (signal qui notifie la plupart des processus de relire leur fichier de configuration) :
# kill -HUP `head -1 /var/run/sendmail.pid`
La plupart des problèmes rencontrés avec POP sont liés aux fichiers temporaires et aux fichiers verrous. Si votre serveur POP renvoie une erreur du type :
-ERR Couldn't open temporary file, do you own it?
Essayez de positionner les permissions comme suit :
permission in /var
drwxrwxr-x 2 bin mail 512 May 26 20:08 mail
permissions in /var/mail
-rw------- 1 username username 0 May 26 20:08 username
Vérifiez aussi que l'utilisateur possède son propre fichier /var/mail. Bien évidemment, ceci devrait être le cas (comme par exemple l'utilisateur joe qui possède /var/mail/joe) mais si ça n'a pas été configuré proprement, le problème viendrait de là !
Bien entendu, si vous donner l'accès à /var/mail en écriture au groupe mail, vous allez probablement vous exposer à des vagues et obscurs problèmes de sécurité. Il se pourrait que ça ne pose aucun problème mais on ne sait jamais (et particulièrement si vous êtes un site de haut vol, un FAI,...) ! Il existe plusieurs services POP de la collection de ports OpenBSD. Si possible, utilisez popa3d(8) disponible dans le système de base d'OpenBSD. Ou peut-être vous avez sélectionné les mauvaises options pour votre programme POP serveur (comme le dot locking). Ou vous avez peut-être simplement besoin de changer le répertoire dans lequel les verrous sont crées (bien que les opérations de verrouillage ne devraient être bénéfiques qu'au service POP).
Note : Il est à noter que OpenBSD n'a pas de groupe "mail". Vous devez en créer un, si nécessaire, dans le fichier /etc/group. La ligne suivante devrait suffire :
mail:*:6:
Par défaut, Sendmail utilise le DNS pour la résolution de nom, non le fichier /etc/hosts. Ce comportement peut être changé par l'usage du fichier /etc/mail/service.switch.
Si vous désirez interroger le fichier d'hôtes avant les serveurs DNS, créez un fichier /etc/mail/service.switch contenant les lignes suivantes :
hosts files dns
Si vous désirez n'interroger QUE le fichier d'hôtes, utilisez ce qui suit :
hosts files
Envoyez un signal HUP à Sendmail :
# kill -HUP `head -1 /var/run/sendmail.pid`
et les changements prendront effet.
OpenBSD est fourni avec des bibliothèques RSA et un service httpd supportant SSL. Pour utiliser SSL avec httpd(8), vous devez d'abord créer un certificat. Ce certificat sera stocké dans /etc/ssl avec la clef correspondante dans /etc/ssl/private/. Les étapes décrites ici sont en partie prises de la page de manuel ssl(8). Lisez la pour plus d'informations. Cette partie de la FAQ s'intéresse seulement à la génération d'un certificat RSA pour les serveurs Web. Elle ne décrit pas les certificats serveur DSA. Pour plus d'informations à ce sujet, lisez la page de manuel ssl(8).
Pour commencer, vous aurez besoin de créer votre clé serveur et le certificat en utilisant OpenSSL :
# openssl genrsa -out /etc/ssl/private/server.key 1024
Ou si vous voulez que la clé soit cryptée avec un mot de passe que vous devez saisir à chaque démarrage des serveurs
# openssl genrsa -des3 -out /etc/ssl/private/server.key 1024
La prochaine étape consiste à générer une requête de signature de certificat qui est utilisée pour permettre à une autorité de certification (CA) de signer votre certificat. Pour cela, utilisez la commande suivante :
# openssl req -new -key /etc/ssl/private/server.key -out /etc/ssl/private/server.csr
Le fichier server.csr pourra alors être communiqué à une autorité de certification qui signera la clé. Une de ces autorités est Thawte Certification que vous pourrez joindre à l'adresse http://www.thawte.com/.
Si vous ne pouvez pas vous permettre un tel service, ou si vous voulez auto signer le certificat, vous pouvez utiliser la commande suivante :
# openssl x509 -req -days 365 -in /etc/ssl/private/server.csr \
-signkey /etc/ssl/private/server.key -out /etc/ssl/server.crt
Avec /etc/ssl/server.crt et /etc/ssl/private/server.key, vous devez être désormais capable de démarrer httpd(8) avec le drapeau -DSSL (consultez la section à propos de rc(8) dans cette faq), activant ainsi les transactions https sur le port 443 de votre machine.
Si vous éditez /etc/passwd, vos modifications seront perdues. OpenBSD génère /etc/passwd dynamiquement avec pwd_mkdb(8). Le fichier principal de mots de passe sous OpenBSD est /etc/master.passwd. D'après pwd_mkdb(8),
FILES
/etc/master.passwd fichier courant de mots de passe
/etc/passwd fichier de mots de passe au style "6th Edition"
/etc/pwd.db fichier non sécurisé de mots de passe au format base de données
/etc/pwd.db.tmp fichier temporaire
/etc/spwd.db fichier sécurisé de mots de passe au format base de données
/etc/spwd.db.tmp fichier temporaire
Dans un fichier de mots de passe Unix traditionnel, toutes les informations y compris le mot de passe crypté de l'utilisateur sont à la disposition de n'importe quel utilisateur du système (et c'est la cible principale de programmes tels que Crack). 4.4BSD a introduit le fichier master.passwd qui a un format étendu (avec les options additionnelles par rapport à /etc/passwd). Ce fichier n'est accessible que pour root. Pour un accès plus rapide aux données, les appels à la bibliothèque qui utilisent ce type d'informations accèdent normalement à /etc/pwd.db et à /etc/spwd.db.
OpenBSD met à votre disposition un outil qui vous permet d'éditer le fichier de mots de passe. Cet outil s'appelle vipw(8). vipw utilisera vi (ou votre éditeur favori tel que défini par $EDITOR) pour éditer /etc/master.passwd. Suite à vos modifications, vipw recréera /etc/passwd, /etc/pwd.db et /etc/spwd.db qui tiendront compte de vos modifications. vipw verrouille aussi l'accès à ces fichiers de telle façon à en interdire l'accès à quiconque essaie d'en changer le contenu en même temps que vous.
OpenBSD offre deux commandes pour facilement créer des comptes utilisateurs sur le système :
Il est toujours possible de créer des utilisateurs à la main en utilisant vipw(8), mais cela complique la plupart des étapes.La manière la plus facile pour créer un compte utilisateur sous OpenBSD est d'utiliser le script adduser(8). Ce script est paramétrable à travers le fichier /etc/adduser.conf. adduser(8) permet d'effectuer des vérifications sur la cohérence de /etc/passwd, /etc/group et les bases de données shell. adduser(8) crée pour vous les entrées correspondantes et les répertoires $HOME. Il peut aussi envoyer un message de bienvenue aux utilisateurs. Le comportement de ce programme peut être adapté à vos besoins. Pour illustrer notre propos, prenons comme exemple la création du compte testuser. Le répertoire de cet utilisateur sera /home/testuser. L'utilisateur fera partie du groupe guest comme groupe et aura un shell /bin/ksh .
# adduser
Use option ``-silent'' if you don't want to see all warnings and questions.
Reading /etc/shells
Reading /etc/login.conf
Check /etc/master.passwd
Check /etc/group
Ok, let's go.
Don't worry about mistakes. I will give you the chance later to correct any input.
Enter username []: testuser
Enter full name []: Test FAQ User
Enter shell csh ksh nologin sh [sh]: ksh
Uid [1002]: Entrée
Login group testuser [testuser]: guest
Login group is ``guest''. Invite testuser into other groups: guest no
[no]: no
Login class auth-defaults auth-ftp-defaults daemon default staff
[default]: Entrée
Enter password []: Type password, then Enter
Enter password again []: Type password, then Enter
Name: testuser
Password: ****
Fullname: Test FAQ User
Uid: 1002
Gid: 31 (guest)
Groups: guest
Login Class: default
HOME: /home/testuser
Shell: /bin/ksh
OK? (y/n) [y]: y
Added user ``testuser''
Copy files from /etc/skel to /home/testuser
Add another user? (y/n) [y]: n
Goodbye!
Pour supprimer des comptes utilisateurs, utilisez la commande rmuser(8). Cette commande supprimera toute chose relative à l'utilisateur. Elle supprimera son entrée crontab(1), son répertoire $HOME (s'il lui appartient) et son courrier. Bien évidemment, cette commande supprimera aussi les entrées correspondantes dans /etc/passwd et /etc/group. Comme exemple, nous allons utiliser cette commande pour supprimer le compte utilisateur précédemment crée. Notez que la commande vous demande l'identifiant du compte et si oui ou non elle doit supprimer le répertoire home de l'utilisateur.
# rmuser
Enter login name for user to remove: testuser
Matching password entry:
testuser:$2a$07$ZWnBOsbqMJ.ducQBfsTKUe3PL97Ve1AHWJ0A4uLamniLNXLeYrEie:1002
:31::0:0:Test FAQ User:/home/testuser:/bin/ksh
Is this the entry you wish to remove? y
Remove user's home directory (/home/testuser)? y
Updating password file, updating databases, done.
Updating group file: done.
Removing user's home directory (/home/testuser): done.
Ces outils sont moins interactifs que la commande adduser(8), ce qui en facilite l'usage dans des scripts.
La liste complète des outils est :
Etant donné que la commande user(8) n'est pas interactive, la manière la plus simple et la plus efficace pour créer des comptes utilisateurs est d'utiliser la commande adduser(8). La commande /usr/sbin/user est seulement une interface aux autres commandes /usr/sbin/user*. Ainsi, dans l'exemple qui suit il est possible d'utiliser soit user add soit useradd. Le choix est votre et ne change rien au résultat.
Dans cet exemple, nous allons créer un compte avec les mêmes spécificités que le compte crée précédemment. useradd(8) est bien plus facile à utiliser si vous connaissez les paramètres par défaut avant de créer un compte utilisateur. Ces paramètres se trouvent dans le fichier /etc/usermgmt.conf et peuvent être visualisés comme suit :
$ user add -D
group users
base_dir /home
skel_dir /etc/skel
shell /bin/csh
inactive 0
expire Null (unset)
range 1000..60000
Ces paramètres vont être appliqués à chaque nouveau compte si vous ne changez pas leur valeur en utilisant des options en ligne de commande. Par exemple, dans notre cas nous voulons que l'utilisateur appartienne au groupe guest et non pas à users. Il est à noter que lors de la création des comptes utilisateurs, les mots de passe doivent être spécifiés sous leur forme cryptée en ligne de commande. Vous devez donc utiliser, au préalable, l'utilitaire encrypt(1) pour créer le mot de passe. Par exemple : Les mots de passe par défaut sous OpenBSD utilisent l'algorithme Blowfish avec 6 réitérations. Voici un exemple d'utilisation de la commande encrypt :
$ encrypt -p -b 6
Enter string:
$2a$06$YOdOZM3.4m6MObBXjeZtBOWArqC2.uRJZXUkOghbieIvSWXVJRzlq
Maintenant que nous avons le mot de passe crypté, nous sommes prêts à créer le compte utilisateur :
# user add -p '$2a$06$YOdOZM3.4m6MObBXjeZtBOWArqC2.uRJZXUkOghbieIvSWXVJRzlq' -u 1002 \
-s /bin/ksh -c "Test FAQ User" -m -g guest testuser
Remarque : Assurez vous d'utiliser " pour englober le mot de passe. L'utilisation de "" ne permet pas d'empêcher le shell d'interpréter le jeu de caractères correspondant au mot de passe avant de les communiquer à user(8). De même, assurez vous d'utiliser l'option -m si vous voulez créer le répertoire $HOME de l'utilisateur et copier les fichiers à partir de /etc/skel vers $HOME.
Pour voir si le compte utilisateur a été correctement crée, nous pouvons recourir à plusieurs utilitaires. Voici quelques commandes pour vérifier rapidement que tout s'est bien passé :
$ ls -la /home
total 14
drwxr-xr-x 5 root wheel 512 May 12 14:29 .
drwxr-xr-x 15 root wheel 512 Apr 25 20:52 ..
drwxr-xr-x 24 ericj wheel 2560 May 12 13:38 ericj
drwxr-xr-x 2 testuser guest 512 May 12 14:28 testuser
$ id testuser
uid=1002(testuser) gid=31(guest) groups=31(guest)
$ finger testuser
Login: testuser Name: Test FAQ User
Directory: /home/testuser Shell: /bin/ksh
Last login Sat Apr 22 16:05 (EDT) on ttyC2
No Mail.
No Plan.
En plus de ces commandes, user(8) fournit son propre utilitaire, appelé userinfo(8), qui permet d'afficher les caractéristiques d'un compte utilisateur :
$ userinfo testuser
login testuser
passwd *
uid 1002
groups guest
change Wed Dec 31 19:00:00 1969
class
gecos Test FAQ User
dir /home/testuser
shell /bin/ksh
expire Wed Dec 31 19:00:00 1969
Pour supprimer des comptes utilisateurs avec la hiérarchie de commandes user(8), vous devez utiliser userdel(8). Cette commande est simple et efficace. Pour supprimer le compte précédemment crée, utilisez :
# userdel -r testuser
Notez bien l'option -r qui doit être spécifiée si vous voulez supprimer les répertoires $HOME aussi. Si vous voulez juste bloquer l'accès au compte sans supprimer des informations liées au compte, utilisez -p au lieu de -r.
Il y a plusieurs méthodes pour effectuer cette opération. Une des manières les plus communes est d'ajouter /usr/bin/false" à "/etc/shells". A partir de là, lorsque vous affectez "/usr/bin/false" à un utilisateur, il ne sera plus capable d'ouvrir une session interactive sur le système, néanmoins il pourra utiliser le service ftp. Vous souhaiterez peut-être aussi restreindre l'accès en Confiner les utilisateurs à leur répertoire HOME avec ftpd(8).
Les quotas sont utilisés pour limiter l'espace disque disponible pour les utilisateurs. Ce système peut être très utile si vous avez des ressources limitées. Les quotas peuvent être configurés par utilisateur et/ou par groupe.
La première étape pour configurer les quotas est de s'assurer que option QUOTA est présente dans votre configuration noyau. Cette option est incluse dans le noyau GENERIC. Ensuite, vous aurez besoin de marquer les systèmes de fichiers où les quotas sont utilisés dans le fichier /etc/fstab. Les mots clés userquota et groupquota doivent être utilisés pour marquer chaque système de fichiers où les quotas sont activés. Par défaut, les fichiers quota.user et quota.group seront crées à la racine des systèmes de fichiers où les quotas sont utilisés pour stocker les informations relatives à ces derniers. Si vous voulez les créer ailleurs, spécifiez un fichier avec l'option des quotas dans /etc/fstab, par exemple "userquota=/var/quotas/quota.user". Voici un exemple de /etc/fstab avec un système de fichiers avec quotas activés et le fichier de quotas se trouvant dans un endroit non-standard :
/dev/wd0a / ffs rw,userquota=/var/quotas/quota.user 1 1
Maintenant, il faut configurer les quotas par utilisateur. A cette fin, nous utilisons la commande edquota(8). Une utilisation simple est "edquota <user>". edquota(8) va utiliser vi(1) pour éditer les quotas à moins que la variable d'environnement EDITOR est positionnée pour charger un autre éditeur. Par exemple la commande :
# edquota ericj
Affichera un résultat similaire à :
Quotas for user ericj:
/: blocks in use: 62, limits (soft = 0, hard = 0)
inodes in use: 25, limits (soft = 0, hard = 0)
Pour ajouter des limites, éditer là pour donner un résultat similaire à :
Quotas for user ericj:
/: blocks in use: 62, limits (soft = 1000, hard = 1050)
inodes in use: 25, limits (soft = 0, hard = 0)
Notez que l'allocation de quotas est en blocs de 1k. Dans ce cas-ci, softlimit est fixé à 1000k et hardlimit à 1050k. softlimit est une limite qui permet au système de prévenir les utilisateurs quand ils l'ont dépassé. Ils auront alors jusqu'à la fin de leur période de grâce pour redescendre en dessous de cette limite. Les périodes de grâce peuvent être configurées à l'aide de l'option -t de edquota(8). Après la fin de la période de grâce, softlimit est géré comme hardlimit. Ce qui cause un échec d'allocation.
Une fois les quotas configurés, il faut les activer. Pour cela, utilisez la commande quotaon(8). Par exemple :
# quotaon -a
Cette commande analysera le contenu de /etc/fstab et activera les quotas sur les systèmes de fichiers où les options de quota sont positionnées. Maintenant que les quotas sont activés, vous pouvez les visualiser à l'aide de quota(1). Ainsi, la commande "quota <user>" fournit les informations concernant cet utilisateur. Si aucun argument n'est utilisé, quota vous fournira des statistiques sur les quotas. Par exemple :
# quota ericj
Afficherait :
Disk quotas for user ericj (uid 1001):
Filesystem blocks quota limit grace files quota limit grace
/ 62 1000 1050 27 0 0
Par défaut, les quotas positionnés dans /etc/fstab seront activés au démarrage. Pour les désactiver, utilisez :
# quotaoff -a
OpenBSD inclut KerberosV comme un composant pré-installé sur le système par défaut.
Pour plus d'information concernant KerberosV, sur votre système OpenBSD, utilisez la commande :
# info heimdal
Le mode FTP anonyme permet à des utilisateurs sans compte d'accéder aux fichiers sur votre machine en utilisant le protocole de transfert de fichiers. Ce chapitre a pour but de fournir une vue d'ensemble de la configuration d'un serveur FTP anonyme, les logs générés, etc...
La première étape consiste à créer un compte ftp sur votre système. Ce compte ne doit pas avoir de mot de passe utilisable. Dans cet exemple, nous allons considérer que /home/ftp est le répertoire correspondant au compte "ftp" mais vous n'êtes pas obligé de choisir la même chose. Quand le mode anonyme est utilisé, le démon ftp va se confiner au répertoire HOME de l'utilisateur ftp (dans notre cas, ce répertoire est /home/ftp). Pour en savoir plus, lisez les pages du manuel ftpd(8) et chroot(2). Voici un exemple de création du compte ftp en utilisant la commande adduser(8). Au préalable, nous avons besoin d'ajouter /usr/bin/false au fichier /etc/shells. C'est le shell que nous allons attribuer à l'utilisateur ftp. Il ne permettra pas de connexion en login à ce compte même si nous configurons un mot de passe vide. Pour effectuer cette opération, il suffit de faire
echo /usr/bin/false >> /etc/shells
# adduser
Use option ``-silent'' if you don't want to see all warnings and questions.
Reading /etc/shells
Reading /etc/login.conf
Check /etc/master.passwd
Check /etc/group
Ok, let's go.
Don't worry about mistakes. I will give you the chance later to correct any input.
Enter username []: ftp
Enter full name []: anonymous ftp
Enter shell csh false ksh nologin sh tcsh zsh [sh]: false
Uid [1002]: Entrée
Login group ftp [ftp]: Entrée
Login group is ``ftp''. Invite ftp into other groups: guest no
[no]: no
Login class auth-defaults auth-ftp-defaults daemon default staff
[default]: Entrée
Enter password []: Entrée
Set the password so that user cannot logon? (y/n) [n]: y
Name: ftp
Password: ****
Fullname: anonymous ftp
Uid: 1002
Gid: 1002 (ftp)
Groups: ftp
Login Class: default
HOME: /home/ftp
Shell: /usr/bin/false
OK? (y/n) [y]: y
Added user ``ftp''
Copy files from /etc/skel to /home/ftp
Add another user? (y/n) [y]: n
Goodbye!
L'opération a crée, en plus de l'utilisateur, le répertoire /home/ftp. C'est ce que nous voulons mais nous avons besoin d'effectuer quelques modifications pour préparer le système à héberger le service FTP anonyme. Ces modifications sont expliquées dans la page du manuel ftpd(8).
Vous n'avez pas besoin de créer un répertoire /home/ftp/usr ou /home/ftp/bin.
Il est à noter que tous ces répertoires doivent être la propriété de "root". Voici à quoi doivent ressembler les répertoires après leur création :
# pwd
/home
# ls -laR ftp
total 5
dr-xr-xr-x 5 root ftp 512 Jul 6 11:33 .
drwxr-xr-x 7 root wheel 512 Jul 6 10:58 ..
dr-x--x--x 2 root ftp 512 Jul 6 11:34 etc
dr-xr-xr-x 2 root ftp 512 Jul 6 11:33 pub
ftp/etc:
total 43
dr-x--x--x 2 root ftp 512 Jul 6 11:34 .
dr-xr-xr-x 5 root ftp 512 Jul 6 11:33 ..
-r--r--r-- 1 root ftp 316 Jul 6 11:34 group
-r--r--r-- 1 root ftp 40960 Jul 6 11:34 pwd.db
ftp/pub:
total 2
dr-xr-xr-x 2 root ftp 512 Jul 6 11:33 .
dr-xr-xr-x 5 root ftp 512 Jul 6 11:33 ..
Vous pouvez choisir d'exécuter ftpd soit à partir de inetd(8) soit de le lancer directement via les scripts rc. Les exemples suivants vous montreront le service lancé via inetd.conf. Tout d'abord, nous devons nous familiariser avec quelques options de ftpd. La ligne par défaut dans /etc/inetd.conf est :
ftp stream tcp nowait root /usr/libexec/ftpd ftpd -US
Comme vous pouvez le voir, ftpd est invoqué avec -US. Ces options vont permettre de loguer les connexions anonymes dans /var/log/ftpd et les sessions courantes dans /var/run/utmp. Ce qui permet de voir ces sessions via who(1). Dans certains cas, on souhaitera fournir un accès anonyme et désactiver ftp pour les utilisateurs du système. Pour cela, il faut utiliser l'option -A de ftpd. Voici une ligne d'invocation de ftpd en mode anonyme exclusif. On utilise aussi -ll qui logue chaque connexion vers syslog en plus des commandes ftp get, retrieve, etc...
ftp stream tcp nowait root /usr/libexec/ftpd ftpd -llUSA
Note : Les personnes gérant des serveurs ftp à HAUT trafic ne devraient pas invoquer ftpd à partir de inetd.conf. La meilleure option consiste à commenter la ligne correspondant à ftpd dans /etc/inetd.conf et à démarrer ftpd à partir de rc.conf.local avec l'option -D. Ce qui va démarrer ftpd en tant que démon. Ce mode de fonctionnement est beaucoup moins coûteux et plus rapide que le démarrage via inetd. La ligne correspondant à ftpd dans rc.conf.local ressemblerait à :
ftpd_flags="-DllUSA" # for non-inetd use: ftpd_flags="-D"
Bien évidemment, cette méthode ne fonctionnera que si ftpd est commenté dans /etc/inetd.conf et en veillant qu'inetd ait bien relu son fichier de configuration.
Par défaut, lorsque les utilisateurs se connectent en ftp, ils peuvent aller dans n'importe quel répertoire du système, dans la mesure où les contrôles d'accès leur permettent. Dans certains cas, ce comportement peut ne pas être souhaitable. Il est possible de restreindre les utilisateurs ftp à leur répertoire HOME en utilisant "chroot".
Si vous voulez autoriser les connexions ftp en chroot, utilisez l'option -A de ftpd(8).
Si vous voulez utiliser chroot de manière plus fine, consultez "login capability infrastructure" et ftpd(8)
Les utilisateurs appartenant à une classe de connexion où la variable ftp-chroot est positionnée seront automatiquement mis dans un chroot. De plus, vous pouvez ajouter un nom d'utilisateur au fichier /etc/ftpchroot pour mettre ces utilisateurs dans un chroot. Un utilisateur a uniquement besoin d'être listé dans un de ces endroits.
Même avec OpenBSD, des bogues apparaissent de temps à autre. Certaines bogues causent des problèmes de fiabilité (par exemple, quelque chose peut amener le système à ne plus fonctionner correctement). D'autres bogues causent des problèmes de sécurité (qui peuvent permettre à d'autres personnes d'utiliser votre machine de façon inattendue). Lorsqu'un bogue critique est trouvé, le correctif sera mis en place au niveau de l'arborescence du code source -current. Ce correctif sera ensuite propagé vers les versions maintenues d'OpenBSD. Ces correctifs apparaissent sur la page web des errata. Ils sont séparés en correctifs "communs" applicables à toutes les plates-formes, et en correctifs applicables à une ou plusieurs plates-formes mais pas toutes.
Cependant, il est à noter qu'il n'y a pas de correctifs pour les nouvelles fonctionnalités ajoutées à OpenBSD. Les correctifs corrigent uniquement des problèmes de stabilité ou de sécurité qui doivent être réglés très rapidement sur les systèmes impactés (mais pas tous les systèmes vu que l'application de tel ou tel correctif dépend des applications utilisées).
Il existe trois façons d'installer les correctifs sur votre système :
Tous les correctifs postés sur la page web des errata concernent uniquement l'arborescence des sources de la version indiquée dans cette page. Les autres correctifs qui concernent l'arborescence actuelle de CVS peuvent contenir certaines modifications qui ne sont peut-être pas désirables sur la version de production. Ceci est important : Si vous avez installé un snapshot et que vous avez téléchargé les arborescences du code source au moment où vous avez obtenu le snapshot, il se peut que si vous essayer d'appliquer un des correctifs publiés, ça ne marche pas à cause d'une modification du code source.
Les correctifs d'OpenBSD sont distribués sous la forme de fichiers diff unifiés. Ces fichiers sont des fichiers texte qui contiennent les différences par rapport au code source d'origine. Ils ne sont PAS distribués sous forme binaire. Cela veut dire que pour appliquer les correctifs, vous devez avoir à disposition sur votre système le code source de la version RELEASE d'OpenBSD. De manière générale, vous devriez avoir à disposition l'arborescence complète du code source. Si votre machine héberge une version à partir d'un CDROM officiel, l'arborescence du code source est disponible sur le disque 3. Elle est aussi disponible sous forme de fichiers à partir des serveurs FTP. Nous allons désormais supposer que vous avez l'arborescence complète à votre disposition.
A titre d'exemple, nous allons appliquer le correctif 001 pour OpenBSD qui corrige un bogue au niveau du pilote st(4) qui gère les lecteurs de bandes magnétiques. Sans ce correctif, la restoration de sauvegardes est assez difficile. Les personnes utilisant un lecteur de bandes magnétiques ont besoin de ce correctif. Les autres personnes peuvent s'en passer. Jetons un coup d'oeil à ce correctif :
# more 001_st.patch
Apply by doing:
patch -p0 < 001_st.patch
Rebuild your kernel.
Index: sys/scsi/st.c
===================================================================
RCS file: /cvs/src/sys/scsi/st.c,v
retrieving revision 1.41
retrieving revision 1.41.2.1
diff -u -p -r1.41 -r1.41.2.1
--- sys/scsi/st.c 1 Aug 2004 23:01:06 -0000 1.41
+++ sys/scsi/st.c 2 Nov 2004 01:05:50 -0000 1.41.2.1
@@ -1815,7 +1815,7 @@ st_interpret_sense(xs)
u_int8_t skey = sense->flags & SSD_KEY;
int32_t info;
- if (((sense->flags & SDEV_OPEN) == 0) ||
+ if (((sc_link->flags & SDEV_OPEN) == 0) ||
(serr != 0x70 && serr != 0x71))
return (EJUSTRETURN); /* let the generic code handle it */
# cd /usr/src
# patch -p0 < 001_st.patch
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|Apply by doing:
| cd /usr/src
| patch -p0 < 001_st.patch
|
|Rebuild your kernel.
|
|Index: sys/scsi/st.c
|===================================================================
|RCS file: /cvs/src/sys/scsi/st.c,v
|retrieving revision 1.41
|retrieving revision 1.41.2.1
|diff -u -p -r1.41 -r1.41.2.1
|--- sys/scsi/st.c 1 Aug 2004 23:01:06 -0000 1.41
|+++ sys/scsi/st.c 2 Nov 2004 01:05:50 -0000 1.41.2.1
--------------------------
Patching file sys/scsi/st.c using Plan A...
Hunk #1 succeeded at 1815. <-- Ce message indique le
succès de l'opération
done
Vous pouvez maintenant recompiler le noyau comme d'habitude, l'installer et redémarrer le système.
Les correctifs ne s'appliquent pas systématiquement au noyau. Dans certains cas, vous devrez recompiler des utilitaires. Dans d'autres, vous devrez recompiler tous les utilitaires liés statiquement à une bibliothèque sujette à correction. Suivez les instructions dans l'en-tête du correctif, et si vous n'êtes pas certain, recompilez tout le système.
Les correctifs qui n'impactent pas directement votre utilisation du système n'ont pas besoin d'être appliqués normalement. Par exemple, si vous n'aviez pas de lecteur de bande magnétique dans votre système, vous ne bénéficierez pas du correctif ci-dessus. Cependant, les correctifs sont supposés être appliqués dans l'ordre. Il est donc possible qu'un correctif ultérieur dépend d'un correctif apparu plutôt. Soyez conscient de ce mode de fonctionnement si vous sélectionnez la méthode consistant à choisir vous-même vos correctifs. Si vous avez un doute, appliquez-les tous, dans l'ordre de leur mise à disposition.
Sous OpenBSD, le serveur httpd(8) d'Apache est chroot(2)é par défaut. Etant un grand pas en avant du point de vue de la sécurité, cela peut créer des problèmes si vous n'y êtes pas préparé.
En gros, chroot(2)er Apache est quelque chose qui n'est pas adopté par la plupart des autres systèmes d'exploitation. Beaucoup d'applications et de configurations système ne fonctionneront plus comme avant sans aménagement. De plus, il faut se souvenir que sécurité et commodité sont souvent incompatibles. L'implémentation d'Apache sous OpenBSD ne sacrifie pas la sécurité aux profit des capacités ou de la "facilité".
# apachectl stop
rename your log files
# apachectl start ; sleep 10 ; apachectl start
Tout d'abord, nous installons le paquetage wwwcount. Nous le configurons et le testons et c'est là que nous en déduisons qu'il ne semble pas fonctionner : Apache nous affiche le message "Internal Server Error". La première étape consiste à arrêter Apache et à le redémarrer avec l'option -u pour vérifier que le problème vient bien du chroot(2) et pas de la configuration système.
# apachectl stop
/usr/sbin/apachectl stop: httpd stopped
# httpd -u
# apachectl stop
/usr/sbin/apachectl stop: httpd stopped
# httpd
Un bon point pour commencer serait de supposer que wwwcount utilise des bibliothèques et d'autres fichiers qu'il ne peut accéder une fois dans le chroot. On peut utiliser à cet effet la commande ldd(1) pour trouver les dépendances dynamiques dont le CGI a besoin :
# cd /var/www/cgi-bin/
# ldd Count.cgi
Count.cgi:
Start End Type Ref Name
00000000 00000000 exe 1 Count.cgi
03791000 237ca000 rlib 1 /usr/lib/libc.so.30.3
03db4000 03db4000 rtld 1 /usr/libexec/ld.so
# mkdir -p /var/www/usr/lib /var/www/usr/libexec
# cp /usr/lib/libc.so.30.3 /var/www/usr/lib
# cp /usr/libexec/ld.so /var/www/usr/libexec
Au moins, le programme s'exécute maintenant et nous affiche des messages d'erreur directement : "Unable to open config file for reading". Nous avons bien progressé mais nous n'avons pas encore fini. Le fichier de configuration se trouve normalement dans le répertoire /var/www/wwwcount/conf, mais au sein de l'environnement chroot, le programme devrait le voir sous /wwwcount/conf. Nous avons donc deux options. Soit nous recompilons le programme pour qu'il tienne compte du nouveau fichier de configuration par défaut (où plutôt du chemin pour l'atteindre) soit nous déplaçons les fichiers de données. Vu que nous avons installé le programme à partir d'un paquetage, nous prenons l'option 2, à savoir le déplacement des fichiers de données. Afin que nous puissions utiliser exactement la même configuration dans un environnement chroot(2)é ou pas, nous utiliserons un lien symbolique :
# mkdir -p /var/www/var/www
# cd /var/www/var/www
# ln -s ../../wwwcount wwwcount
# tar cf - /usr/local/lib/wwwcount | (cd /var/www; tar xpf - )
Notez que nous n'avons copié que les fichiers strictement nécessaires au bon fonctionnement. En général, seuls les fichiers nécessaires à l'application doivent être copiés dans le chroot.
Toutes les applications ne peuvent ou ne devraient pas être chroot(2)ées.
Le but est la mise en place d'un serveur web sécurisé et le chroot(2)age n'en est qu'un outil, pas un but en soi. Souvenez-vous, la configuration initiale de l'Apache chroot(2)é sous OpenBSD fair en sorte que l'utilisateur sous lequel le programme httpd(8) tourne ne peut pas lancer de programme, ne peut pas modifier de fichiers et ne peut pas prendre l'identité d'un autre utilisateur. Réduire ces restrictions diminuera votre sécurité, chroot ou pas.
Certaines applications sont relativement simples et les mettre dans un chroot(2) n'a aucun sens. D'autres sont très complexes. Elles ne valent pas les efforts nécessaires pour les mettre en chroot(2) et même si c'était le cas, vous perdriez les avantages du chroot(2) après avoir copié la masse importante de fichiers dont elles ont besoin pour fonctionner. Ainsi le programme OpenWebMail a besoin de pouvoir lire et écrire dans le répertoire mail, le répertoire home de l'utilisateur et doit pouvoir travailler en tant que n'importe quel utilisateur du système. Essayer le mettre cette application en chroot serait inutile car vous serez obliger de désactiver tous les bénéfices du chroot(2)age. Même avec des applications aussi simples que le compteur précédent, il doit pouvoir écrire sur le disque (pour garder la trace de ses compteurs) et donc, une partie du bénéfice du chroot(2) est perdue.
Toute application qui doit fonctionne sous root ne vaut pas le coup d'être chroot(2)ée puisque root peut généralement s'échapper du chroot(2).
N'oubliez pas, si la procédure de chroot pour votre application est trop complexe vous pourriez ne pas mettre à jour votre système aussi souvent qu'il le faudrait. Ceci pourrait rendre votre système MOINS sécurisé qu'un système plus facilement administrable et dont le chroot est désactivé.
Le shell par défaut sur OpenBSD de l'utilisateur root est ksh.
Une directive Unix traditionnelle est d'utiliser pour l'utilisateur root des shells compilés statiquement, car si votre système démarre en mode utilisateur unique, les partitions non-root ne seront pas montées et les shells liés dynamiquement ne seront pas capable d'accéder aux bibliothèques situées dans la partition /usr. Ceci n'étant pas très important pour OpenBSD, car le système vous demandera de choisir un shell lors d'un démarrage en mode utilisateur unique, le shell par défaut étant sh. Les trois shells standards sous OpenBSD (csh, sh et ksh) sont liés statiquement et donc utilisables en mode utilisateur unique.
Les utilisateurs qui sont à l'aise avec bash, souvent utilisé sur les systèmes Linux, trouveront probablement ksh très familier. Ksh(1) offre la plupart des options habituellement utilisées avec bash, notamment l'achèvement des commandes avec la touche tab, l'édition de la ligne de commande et l'historique via les touches fléchées, et CTRL-A/CTRL-E pour aller au début/à la fin de la ligne de commande. Si vous désirez d'autres options de bash, bash peut être installé soit via les paquetages ou soit via les ports.
Le prompt de ksh peut être facilement changé de manière à fournir plus d'informations que le simple "$ " par défaut en modifiant la variable PS1. Par exemple, en insérant la ligne suivante :
export PS1='$PWD $ '
/home/nick $
A partir d'OpenBSD 3.7, ksh(1) a été amélioré. Un certain nombre de caractères spéciaux ont été ajoutés au niveau de la chaîne primaire de l'invite de commandes, PS1. Ces caractères sont similaires à ceux présents dans bash. Par exemple :
\e - Insertion d'un caractère d'échappement ASCII.(consultez la page du manuel ksh(1) pour plus de détails , et beaucoup, beaucoup plus de caractères spéciaux ! Veuillez noter que le caractère "$" a une signification spéciale à l'intérieur des double quotes. Il est donc à manipuler avec précaution)
\h - Le nom d'hôte sans le nom de domaine.
\H - Le nom d'hôte complet, avec le nom de domaine.
\n - Insertion d'un caractère de retour à la ligne.
\t - L'heure actuelle, sur 24 heures, au format HH:MM:SS.
\u - Le nom de l'utilisateur actuel.
\w - Le répertoire de travail actuel. $HOME est abrégé en `~'.
\W - La racine du répertoire de travail actuel.
\$ - Affiche "#" pour les super-utilisateurs, et "$" pour les autres
Vous pouvez par exemple utiliser la commande suivante :
export PS1="\n\u@\H\n\w \\$ "
[Index de la FAQ] [Section 9 - Migrer vers OpenBSD] [Section 11 - Le système X Window]
![[back]](../../images/back.gif){kind=small}
www@openbsd.org