su avec mot de pass lancé en script depuis une console user

su avec mot de pass lancé en script depuis une console user - Codes et scripts - Linux et OS Alternatifs

Marsh Posté le 14-07-2005 à 12:18:02    

J'ai des pbs avec mon fstab et suis incapable de monter en rwx pour un user une partition NTFS distante depuis MDK10.2 au démarrage.
 
Donc, j'ai tenté de modifier mon rc.local pour monter ce partage mails il ne s'active pas.
 
Pourtant, en faisant un copié-collé du script mount -t smbfs etc.. du rc.local à une console en root, tout baigne : je peux enfin, en tant que usr_lambda lire, écrire ou exécuter sur une partition distante ntfs.
 
J'avais déjà modifié le rc.local pour permettre un démarrage auto de ma connexion ADSL et ça fonctionne.
 
 
Mon but est donc de modifier le .profile de l'user de sorte à lancer ce script mount -t smbfs etc.. MAIS EN TANT QUE ROOT
 
Si je fais un su password=motepass ou su motdepass, il me demandera d'agir interactivement pour entrer le mot de passe.
 
Dans le man su, je ne vois pas d'option qui me permette de me logguer.
 
PS : Je me permets de mettre ce post dans "réseaux" aussi car c'est un peu les deux non ?

Reply

Marsh Posté le 14-07-2005 à 12:18:02   

Reply

Marsh Posté le 14-07-2005 à 12:24:44    

Pour revenir au pb du fstab, si tu passe l'option user=toto,password=tata dans la ligne correspondante au montage de cette partition dans ton fstab, ca ne marche toujours pas ? (Le toto et tata sont les identifiants pour samba.)
 
Sinon, pour lancer un script en tant que root, tu as sudo (qui demandera a l'utilisateur SON password, mais ce n'est peut-etre pas ce que tu veux) ou alors il faut executer le script pendant le demarrage, comme tu l'as deja fait.
 
[EDIT] supprime l'un des deux post, c'est inutile puisque la plupart des gens ne se cantonne pas à une sous-cat donc ils voient ton post 2 fois


Message édité par sebchap le 14-07-2005 à 12:26:32
Reply

Marsh Posté le 14-07-2005 à 12:36:21    

sebchap a écrit :

Pour revenir au pb du fstab, si tu passe l'option user=toto,password=tata dans la ligne correspondante au montage de cette partition dans ton fstab, ca ne marche toujours pas ? (Le toto et tata sont les identifiants pour samba.)
 
Non, j'ai vraiment tenter beaucoup de choses, et voici mon mount qui fonctionne à merveille :
 
mount -t smbfs -o username=administrateur,password=kiki,uid=500,gid=500,fmask=777,dmask=777,debug=0 //MINIPC/DdeMiniPC /home/mnt/partage
 
où 500 est le fameux user lambda.
 
Sinon, pour lancer un script en tant que root, tu as sudo (qui demandera a l'utilisateur SON password, mais ce n'est peut-etre pas ce que tu veux) ou alors il faut executer le script pendant le demarrage, comme tu l'as deja fait.
 
Ben ouai, pis ça fonctionne pas?
 
[EDIT] supprime l'un des deux post, c'est inutile puisque la plupart des gens ne se cantonne pas à une sous-cat donc ils voient ton post 2 fois


 
 
OK, je le fais, désolé  :(

Reply

Marsh Posté le 14-07-2005 à 12:39:13    

merci à jlighty
Je ne sais pas comment on fait pour supprimer un post ..
 
Je vais essayer sudo

Reply

Marsh Posté le 19-07-2005 à 15:17:49    

pour ton pb de su, su -l root -c commande_a_executer...
exemple : su -l root -c mount -t smbfs .... Si c'est un script contenu dans /etc/init.d/ et donc dans les rc.*** ça devrait marcher car c'est le système qui lance le script et non un user.


Message édité par Profil supprimé le 19-07-2005 à 19:16:19
Reply

Marsh Posté le 19-07-2005 à 18:48:41    

Et bien merci Clebig,  
En fait ça fonctionne ainsi avec le .bashrc du user, mais l'embêtant est qu'à chaque fois que je lance une console, il me monte logiquement le même partage, c'est po propre ça ;-)
 
Je vais donc voir directement le rc.local pour le modidier, sachant que puisqu'il est édité par root, en changeant les droits en 777, (pour l'instant), le système pourra l'appliquer ?
 
question bête = comment puis-je mettre le fichier coucou en appartenance à 3 groupes comme groupe1 groupe2 et groupe 3 puisque d'après ce que je comprends il y a sous la convention UNIX propriétaire,groupe et les autres ?
 
Mon but pour cette démarche est d'ajouter au système les droits en lecture et en exécution de ce rc.local
D'ailleurs quel est EXACTEMENT le user système qui lit/exécute ce fichier ? adm ?
 
PS : Je ne sais toujours  pas, mais j'assure à TT le monde que j'ai fait ce qu'il fallait dans le fstab pour accéder à mon XP et ce n'est jamais stable, alors que la solution alternative est sans pb.


Message édité par krisofe le 19-07-2005 à 23:25:04
Reply

Marsh Posté le 21-07-2005 à 19:14:33    

krisofe a écrit :

Et bien merci Clebig,  
En fait ça fonctionne ainsi avec le .bashrc du user, mais l'embêtant est qu'à chaque fois que je lance une console, il me monte logiquement le même partage, c'est po propre ça ;-)
 
Je vais donc voir directement le rc.local pour le modidier, sachant que puisqu'il est édité par root, en changeant les droits en 777, (pour l'instant), le système pourra l'appliquer ?
 
question bête = comment puis-je mettre le fichier coucou en appartenance à 3 groupes comme groupe1 groupe2 et groupe 3 puisque d'après ce que je comprends il y a sous la convention UNIX propriétaire,groupe et les autres ?
 
Mon but pour cette démarche est d'ajouter au système les droits en lecture et en exécution de ce rc.local
D'ailleurs quel est EXACTEMENT le user système qui lit/exécute ce fichier ? adm ?
 
PS : Je ne sais toujours  pas, mais j'assure à TT le monde que j'ai fait ce qu'il fallait dans le fstab pour accéder à mon XP et ce n'est jamais stable, alors que la solution alternative est sans pb.


 
En fait si tu ne veux pas que ça créé le point de montage à chaque fois que tu ouvres une console, tapes une vérification dans le .bashrc "if ton montage est déja existent, passer à la suite du scripr, else création du point de montage".
 
Je n'ai pas compris ta question bête. Le système Linux et UNIX fonctionne avec des groupes, des users, et des others (tous ceux qui n'appartiennent pas aux groupes et users connus sont les others). Lit la page man de la commande chmod. Un user est un utilisateur enregistré sur le système, un groupe est un utilisateur seul, ou un groupe d'utilisateur, un other n'est pas connu du système. Pour chaque fichier ou dossier, on donne des droits respectifs au propriétaire du fichier, au groupe et aux autres... r pour read (droits de lecture) w pour write (droits en écriture) x pour executable. Si tu tapes la commande ls -lA dans un repertoire, tu verras (pas exemple ici dans le dossier temporaire de ma mule) : -rw-r-----  1 root root 492987518 jui  3 20:13 002.part. Les premières inscriptions à gauches sont les caractéristiques de sécurité du fichier, on lit -rw-r-----, le premier tiret dit que le fichier est un fichier et non un répertoire, le rw signifie que le propriétaire à les droits en lecture et écriture sur le fichier, le tiret avec le r suivant veut dire que le fichier n'est pas executable par le propriétaire sinon on aurait eu -rwxr----- Si le fichier était listé comme ceci : -rwxrwxrwx alors il serait a la foi "readable, writable et executable" pour tout le monde.
 
L'idée de faire ce que tu veux faire via un script de démarrage n'est pas la meilleure solution car il crérait le point de montage à chaque démarrage et pour tout le monde. Les script de démarrage (si tu tapes ls -lA /etc/init.d) sont au user root et au groupe root, seul lui peut les executer. Vu que ce n'est pas un script de démarrage, si tu tiens absolument à créer un script, ne le mets pas dans le répertoire de rc.****, mets le plutot dans un dossier que tu crérais...
 
Pour reprendre ta question "bête", si tu veux donner les droits en lecture et execution a ton fichier (déja il faut savoir à qui tu les donnes, imaginons seulement que tu les donnes au users connus) tu tapes chmod u+rwx,g+rx-w,o-rwx coucou. C'est une façon plus simple que la façon numérique ici on voit u g o suivis respectivement des droits que l'on souhaite donner au fichier séparés par des virgules. u pour user, g pour groupe, o pour other. J'ai donc donner au fichier coucou les droits rwx pour le user, rx-w (lecture execution moins l'écriture) pour le groupe, et -rwx (c a dire nada) pour les autres.  

Reply

Marsh Posté le 25-07-2005 à 11:02:10    

Excuse de mon retard et surtout merci de ton aide ;-)
Pour les permissions, je connaissais les bases, mais en fait pour des raisons de sécurité, j'aimerai par exemple que mon .bashrc propre à un user ne soit lisible ou executable que par lui OU le système, or quel est l'user système, il y en a pleins ?
 
Par exemple, je reprends ton idée de if ... qui est un script annexe que je fais lancr par le user1 via son .bashrc
 
Le pb est que dans ce script, je vérifie si le dir distant existe et, si ce n'est pas le cas, je le monte.
 
De cette façon le montage n'est validé qu'une fois par user1 même s'il lance plein de consoles.
Evidemment, le log et le pass pour monter une partition ntfs distante sont inclus dans mon script, d'où la nécessité pour moi que seuls les usagers SYSTEME et user1 puissent avoir rwx sur ce script.

Reply

Marsh Posté le 11-08-2005 à 00:57:33    

krisofe a écrit :

Excuse de mon retard et surtout merci de ton aide ;-)
Pour les permissions, je connaissais les bases, mais en fait pour des raisons de sécurité, j'aimerai par exemple que mon .bashrc propre à un user ne soit lisible ou executable que par lui OU le système, or quel est l'user système, il y en a pleins ?
 
Par exemple, je reprends ton idée de if ... qui est un script annexe que je fais lancr par le user1 via son .bashrc
 
Le pb est que dans ce script, je vérifie si le dir distant existe et, si ce n'est pas le cas, je le monte.
 
De cette façon le montage n'est validé qu'une fois par user1 même s'il lance plein de consoles.
Evidemment, le log et le pass pour monter une partition ntfs distante sont inclus dans mon script, d'où la nécessité pour moi que seuls les usagers SYSTEME et user1 puissent avoir rwx sur ce script.


 
Par la méthode que je te décris, ton montage n'est effectué qu'après vérification que celui-ci n'existe pas, donc c'est bien ce que tu veux si j'ai bien compris... Le script n'est pas annexe, tu peux inclure toutes ces commandes dans le bashrc, tu peux aussi faire un script à part et le lancer via le .bashrc, libre à toi...
 
pour ce qui est des droits, si le script est inclus dans le .bashrc, alors il te suffit d'enlever le droit en lecture pour les "group" et "others" pour ne pas qu'ils puissent le lire. .bashrc est executé par bash qui est lui même lancé par ton user1, donc chaque fois qu'il ouvrira une console, le script vérifiera si le montage existe et dans le cas contraire il le créera, et seul ton user et root pourront lire le contenu de /home/user1/.bashrc

Reply

Marsh Posté le 11-08-2005 à 01:12:38    

Le solution qui consiste a ajouter des trucs dans ton .bashrc n'est pas bonne sur le principe. .bashrc est la pour initialiser bash, pour pour faire tout et n'importe quoi. .bashrc est aussi execute a chaque fois que tu lance un script, donc tu fini par bien alourdir ton systeme.
 
Je n'ai pas lu tous les posts mais si tu veux simplement que ton fs soit monte automatiquement au boot, il suffit de ne pas mettre l'option "noauto" dans fstab.

Reply

Marsh Posté le 11-08-2005 à 01:12:38   

Reply

Marsh Posté le 11-08-2005 à 01:23:14    

C'est vrai, j'avais oublié que chaque fois que tu lances un script bash, .bashrc est executé...

Reply

Marsh Posté le 21-08-2005 à 09:24:30    

bin j'ai attendu assez longtemps pour répondre, car je voulais  être sûr que ce soit stable :
J'ai suivi l'idée de "je ne sais plus qui et merci à lui" en faisant un if then donc  
Si le montage existe, il n'est pas recréé, mais un echo m'annonce qu'il est bien actif
S'il n'existe pas, il se monte lors du lancement d'un terminal.
 
Ca fonctionne vraiment comme jamais auparavant, mais bien sûr j'aurai préféré que tout ce que j'avais tenté fonctionne avec fstab.
 
 

Reply

Marsh Posté le 21-08-2005 à 22:18:12    

ahhhhhhhhhhhh :)

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed