Samba security users avec partage en utilisation libre

Bonjour,

Avant tout, pas de chown et chmod ! Généralement les fichiers ont les bons droits, donc soit l'utilisateur n'est pas dans les bons groupes et nécessite une élévation de privilège, soit (et c'est probablement le cas ici) le système de fichiers n'a pas été monté avec les bons droits.

Ici les droits côté serveurs sont définis côté sambas. Ils semblent suffisant pour autoriser un partage accessible en écriture. Il faut regarder côté client comment a été monté le système de fichiers samba (cifs), et voir si l'utilisateur avec lequel tu tentes d'écrire sur le partage a des droits suffisant pour écrire dans ces fichiers.

Pour cela, en admettant que le partage soit monté dans /media/samba, reporte-nous les résultats de :

mount | grep cifs
ls -l /media/samba
whoami
groups

Bonne chance

l'écriture fonctionne en faisant un chown -R nobody sur le dossier, ce qui parait cohérent car le partage libre doit être accessible à n'importe qui.

L'accès aux repertoires protégés par validation compte utilisateur pam est bloqué :

Comment parametrer le mount cifs ?

cifs est obligatoire ?

Bonsoir

Comment parametrer le mount cifs ?

cifs est obligatoire ?

Un doute affreux me vient :-)

On est bien d'accord que tu as une machine (le serveur) qui partage par le réseau des fichiers (ici, ceux dans /stockage) à une autre machine (le client) ?

• Si oui : alors tu peux partager les fichiers du serveur au(x) client(s) avec samba (ou une autre technologie). Côté client, il faudra faire un mount -t cifs  ...
• Sinon : pas besoin de samba, puisque tout se fait en local, tu peux définir des droits au moment du mount. Pour le moment tu n'en définis aucun dans /etc/fstab. 
  • Pour un système de fichier Linux (e.g., ext4) : c'est normal, le système de fichiers définit pour chaque fichiers les droits qui lui sont associés.
  • Pour un système de fichier autres (e.g., ntfs ou vfat) : le système de fichiers ne définit pas de droits Linux en tant que tel, et c'est donc au moment du mount qu'on les définit de manière globale à tout ce système de fichiers.
  • Si tu es dans ce cas, il faudrait nous dire quels droits tu veux définir et quel est le système de fichiers de 0c34cac6-10fc-46f8-a114-632a4e612074. Pour cela indique-nous quel est le device associé :

ls -l /dev/disk/by-uuid/0c34cac6-10fc-46f8-a114-632a4e612074

Admettons que ce soit /dev/sdb1, quel est le système de fichiers associé ? Pour cela indique nous le résultat de :

sudo parted -l

Bonne chance 

Je cherche à partager des répertoires d'un disque branché en sata sur un serveur via samba pour que des postes windows, Android puissent y accéder comme sur un partage windows classique...

Il y a 2 types de répertoires, in en accès libre et un par authentification avec le même login que sur le serveur debian.

Le disque est en ext4

J'espère que le contexte est suffisamment exhaustif.

J'enverrais le résultat des commande dès accès à la machine

Oui c'est clair maintenant.

La manière dont tu définis le mount côté serveur me paraît ok, ainsi que les droits qui sont associés à ces fichiers. Il n'y a pas de chmod ou de chown a prévoir tant que l'utilisateur qui lance le démon samba a des droits suffisant (excepté pour le partage [libre]).

Les droits que tu définis dans ton configuration samba montre avec quels droits les fichiers partagés seront exposés aux clients.

Remarques préalable

• Quand un utilisateur se connecte à un serveur samba, il se présente en tant qu'utilisateur samba ou invité. Selon ce choix, il est ensuite considéré par le serveur linux comme l'utilisateur linux correspondant (par exemple, un utilisateur invité, qui n'a saisi aucun login, sera vu "comme si" c'était l'utilisateur spécifié par la directive guest account (par défaut nobody).
• La manière dont est fait le partage limite ce que peuvent faire les utilisateurs dans ce partage. Par exemple, si le partage n'est pas writeable, alors même si le système de fichiers partagé est accessible en écriture, l'utilisateur ne pourra pas écrire. C'est là où /etc/samba/smb.conf entre en jeu.
• Inversement, si l'utilisateur Linux résolu après authentification n'a pas des droits suffisants vis-à-vis du système de fichiers, il ne pourra pas réaliser certaines opérations bien que celles-ci soient autorisées au niveau de la configuration samba. C'est là où chmod et chown peuvent entrer en jeu.

Côté serveur :

Méthode 1 : la configuration peut s'inspirer de ceci (pense à relancer le serveur pour prendre en compte les changements apportés à /etc/samba/smb.conf) :

[global]
workgroup = WORKGROUP
netbios name = HOMESERV
guest account = nobody
security = share
null passwords = yes

[libre]
# Chemin local de la ressource
path = /stockage/libre
# Visible dans la liste des partages
public = yes
# Permettre les accès anonyme
guest ok = yes
# Autoriser le parcours du partage
browseable = yes
# Permettre l'écriture et modification du partage
writeable = yes

Cependants beaucoup de gens semblent dire que la directive null passwords est assez capricieuse. Si tu es dans ce cas, essaye une des méthodes suivantes.

Méthode 2 : on crée un utilisateur invité smbguest (voir ce message) et on corrige les droits du dossier du partagé pour qu'il en devienne propriétaire. Dès qu'un utilisateur est propriétaire d'un dossier, il peut (re)définir les droits de ce fichier (chmod) sans être root. En admettant que le dossier soit vide un simple chown suffit.

useradd smbguest -s /usr/sbin/nologin
smbpasswd -a smbguest
chown -R smbguest /stockage/libre 

Dans /etc/samba/smb.conf on déclare les deux partages (et on relance samba) :

[global]
workgroup = MyWorkGroup
server string = MyServer
security = share
guest account = smbguest
passdb backend = tdbsam

[libre]
path = /stockage/libre
writable = yes
printable = no
public = yes
browseable = yes

[securise]
path = /stockage/securise
writable = yes
printable = no
guest ok = no
browseable = yes
valid users = @smbshare # Uniquement les utilisateurs membres du groupe smbshare

Concernant le partage sécurisé, j'ai ici choisi de dire que l'accès en écriture était possible à tout membre de smbshare. Pour rajouter l'utilisateur toto à ce groupe :

sudo usermod -aG smbshare toto

Méthode 3 : on force l'utilisateur samba invité à correspondre côté serveur à un utilisateur et un groupe système particulier (voir ce message). Le principe est quasiment le même que méthode 2.

Côté client

La procédure dépend du système d'exploitation du client. Ici je parle de Linux. Tu peux comme sous Windows passer par un assistant graphique. Au final cela revient à faire un mount donc je vais plutôt me concentrer sur cet aspect.

Il faut simplement que le client puisse résoudre l'adresse du serveur et qu'il se présente à un partage valide avec des credentials corrects.

mkdir -p /media/securise
mount -t cifs -o credentials=/home/toto/.smbpasswd,iocharset=utf8,nofail //192.168.1.1/securise /media/securise 

mkdir -p /media/libre
mount -t cifs -o guest,iocharset=utf8,nofail //192.168.1.1/libre /media/libre

... où /home/toto/.smbpasswd contient :

username=UTILISATEUR_SAMBA
password=MOT_DE_PASSE_SAMBA

... et où ce fichier a des droits restreints :

chmod 600 /home/toto/.smbpasswd

Bonne chance

j'ai créé un un user samba et paramétré les identifiants dans le fichier utilisé par le mount via cifs, le mount provoque un arrêt du service hostnamed : Failed to start Hostname

Bonjour

En réponse à tes messages

#11

Seule la méthode 3 permet un filtrage par user système au niveau montage et samba.

À partir du moment où tu acceptes des profils invités, ceux-ci sont associé à un utilisateur système. Les trois méthodes proposent trois stratégies pour y arriver mais au final il y a toujours un utilisateur système (par défaut, nobody). Les méthodes 2 et 3 montrent comment définir quel est l'utilisateur samba invité et l'utilisateur système associé.

Il y a moyen de monter sans utiliser l'ip, comme le netbios name ?

1. Si la machine est référencée dans le DNS, tu peux utiliser son nom d'hôte.
2. Tu peux aussi définir un alias dans /etc/hosts.
3. Le nom NetBios nécessite de lancer une requête samba (voir ce message) or /etc/fstab n'est pas prévu pour embarquer du code shell. Tu peux donc résoudre un nom Netbios dans un script shell, mais pas dans /etc/fstab.

#12

La commande hostname -I | awk '{print $1}' sera interprétée dans fstab ?

Non, il faut simplement directement écrire nom d'hôte.

#13

Pour l'ip je peux créer un script exécuté eu démarre et constuire la commande avec l'ip dans une variable préalablement paramétrée à l'ip récupérée via une commande...

par contre j'ai mount error(13): Permission denied sur le mount en essayant dans un terminal avec sudo

• Quelle est la commande que tu lances ?
• Parviens-tu à résoudre le nom de machine ?
• Parviens-tu à pinguer cette IP ?
• Est-ce que le port samba semble ouvert depuis la machine cliente ? (si le client est sous Linux, tu peux vérifier avec nmap).

#14

J'ai créé un un user samba et paramétré les identifiants dans le fichier utilisé par le mount via cifs, le mount provoque un arrêt du service hostnamed : Failed to start Hostname

Peux-tu préciser quelle commande tu lances ?

Bonne chance