Mon mac se fait attaquer par un wanabe hackerz. Ce type essaye (d'apres mes
logs) plein de logins du genre guest, user... Malheureusement il s'est
accroché chez moi parce aue j'ai un utilisarteur qui s'appelle "test".
Heureusement que je n'ai pas mis un mot de passe trivial a cet utilisateur.
Donc, si vous laissez votre port ssh ouvert faisez gaffe au mot de passe.
Ca sert a quelque chose aue je transmette l'IP a orange-wanamou-france
telecom?
--
Sind zu sein und es seiend in einem Schiff. Fällt zu sein hat das Wasser.
Wer bleibt er? -- Heidegger
Deux manières : 1) Essayer de réparer les droits. Mais peut-être qu'il y a mélange des droits si tu as fait une mise à jour d'un 10.3 en 10.4, je ne sais pas, dans ce cas là, si il se mélange pas entre les reçus du 10.3 et ceux du 10.4. Il faudrait essayer de virer les reçus en rapport avec Mac OS X 10.3 du dossier /Library/Receipts/.
Bon je vais essayer ça pour voir si ça retombe en marche sinon je passerai au point
2) Ou sinon, faire : sudo chmod g+r /var/log/secure.log
La deuxième manière est plus facile, mais je pense que la première est plus sûre.
Vu ma capacité à faire des boulettes de retranscription, et vu les conséquances avec un sudo c'est sur que la première méthode est beaucoup plus sûre pour un utilisateur de mon niveau.
Pour mon information peux tu m'expliquer la commande? Sudo = je prends la main comme root le temps de la commande chmod = change mod = changer les propriétés d'un fichier g = ???????? +r = donne le droit en lecture sur le fichier au niveau g, je suppose /var/log/secure.log = le fichier cible à modifier.
Par défaut, seuls les comptes admin sont dans le fichier sudoers, et c'est normal...
Ok merci de cette information. En fait je pensai bètement que tout le monde pouvait être sudoer du moment qu'on connait le log et le pass admin. Finalement c'est mieux comme ça, je pense qu'au niveau sécurité c'est meilleur.
Merci de ton aide
-- Eric
Deux manières :
1) Essayer de réparer les droits. Mais peut-être qu'il y a mélange des
droits si tu as fait une mise à jour d'un 10.3 en 10.4, je ne sais pas,
dans ce cas là, si il se mélange pas entre les reçus du 10.3 et ceux du
10.4. Il faudrait essayer de virer les reçus en rapport avec Mac OS X
10.3 du dossier /Library/Receipts/.
Bon je vais essayer ça pour voir si ça retombe en marche sinon je
passerai au point
2) Ou sinon, faire :
sudo chmod g+r /var/log/secure.log
La deuxième manière est plus facile, mais je pense que la première est
plus sûre.
Vu ma capacité à faire des boulettes de retranscription, et vu les
conséquances avec un sudo c'est sur que la première méthode est beaucoup
plus sûre pour un utilisateur de mon niveau.
Pour mon information peux tu m'expliquer la commande?
Sudo = je prends la main comme root le temps de la commande
chmod = change mod = changer les propriétés d'un fichier
g = ????????
+r = donne le droit en lecture sur le fichier au niveau g, je suppose
/var/log/secure.log = le fichier cible à modifier.
Par défaut, seuls les comptes admin sont dans le fichier sudoers, et
c'est normal...
Ok merci de cette information. En fait je pensai bètement que tout le
monde pouvait être sudoer du moment qu'on connait le log et le pass
admin. Finalement c'est mieux comme ça, je pense qu'au niveau sécurité
c'est meilleur.
Deux manières : 1) Essayer de réparer les droits. Mais peut-être qu'il y a mélange des droits si tu as fait une mise à jour d'un 10.3 en 10.4, je ne sais pas, dans ce cas là, si il se mélange pas entre les reçus du 10.3 et ceux du 10.4. Il faudrait essayer de virer les reçus en rapport avec Mac OS X 10.3 du dossier /Library/Receipts/.
Bon je vais essayer ça pour voir si ça retombe en marche sinon je passerai au point
2) Ou sinon, faire : sudo chmod g+r /var/log/secure.log
La deuxième manière est plus facile, mais je pense que la première est plus sûre.
Vu ma capacité à faire des boulettes de retranscription, et vu les conséquances avec un sudo c'est sur que la première méthode est beaucoup plus sûre pour un utilisateur de mon niveau.
Pour mon information peux tu m'expliquer la commande? Sudo = je prends la main comme root le temps de la commande chmod = change mod = changer les propriétés d'un fichier g = ???????? +r = donne le droit en lecture sur le fichier au niveau g, je suppose /var/log/secure.log = le fichier cible à modifier.
Par défaut, seuls les comptes admin sont dans le fichier sudoers, et c'est normal...
Ok merci de cette information. En fait je pensai bètement que tout le monde pouvait être sudoer du moment qu'on connait le log et le pass admin. Finalement c'est mieux comme ça, je pense qu'au niveau sécurité c'est meilleur.
Merci de ton aide
-- Eric
eric
Deux manières : 1) Essayer de réparer les droits. Mais peut-être qu'il y a mélange des droits si tu as fait une mise à jour d'un 10.3 en 10.4, je ne sais pas, dans ce cas là, si il se mélange pas entre les reçus du 10.3 et ceux du 10.4. Il faudrait essayer de virer les reçus en rapport avec Mac OS X 10.3 du dossier /Library/Receipts/.
Je viens de faire un tour dans /library/receipts/. C'est pas gagné. La réparation des droits ne change rien, ça fait 5 fois que le fais sans modification. Au niveau des receipts, j'ai un peu peur de faire des bétises, je vire que les receipts en rapport avec Mac OS 10.3.x ou il faut aussi virer les security update de cette époque et les composants quicktime de cette époque. Merci de m'éviter de faire une grosse bétise.
Finalement le sudo est peut être beaucoup plus facile :-(
-- Eric
Deux manières :
1) Essayer de réparer les droits. Mais peut-être qu'il y a mélange des
droits si tu as fait une mise à jour d'un 10.3 en 10.4, je ne sais pas,
dans ce cas là, si il se mélange pas entre les reçus du 10.3 et ceux du
10.4. Il faudrait essayer de virer les reçus en rapport avec Mac OS X
10.3 du dossier /Library/Receipts/.
Je viens de faire un tour dans /library/receipts/.
C'est pas gagné. La réparation des droits ne change rien, ça fait 5 fois
que le fais sans modification. Au niveau des receipts, j'ai un peu peur
de faire des bétises, je vire que les receipts en rapport avec Mac OS
10.3.x ou il faut aussi virer les security update de cette époque et les
composants quicktime de cette époque. Merci de m'éviter de faire une
grosse bétise.
Finalement le sudo est peut être beaucoup plus facile :-(
Deux manières : 1) Essayer de réparer les droits. Mais peut-être qu'il y a mélange des droits si tu as fait une mise à jour d'un 10.3 en 10.4, je ne sais pas, dans ce cas là, si il se mélange pas entre les reçus du 10.3 et ceux du 10.4. Il faudrait essayer de virer les reçus en rapport avec Mac OS X 10.3 du dossier /Library/Receipts/.
Je viens de faire un tour dans /library/receipts/. C'est pas gagné. La réparation des droits ne change rien, ça fait 5 fois que le fais sans modification. Au niveau des receipts, j'ai un peu peur de faire des bétises, je vire que les receipts en rapport avec Mac OS 10.3.x ou il faut aussi virer les security update de cette époque et les composants quicktime de cette époque. Merci de m'éviter de faire une grosse bétise.
Finalement le sudo est peut être beaucoup plus facile :-(
-- Eric
Nicolas-MICHEL'_remove_'
eric wrote:
Vu ma capacité à faire des boulettes de retranscription, et vu les conséquances avec un sudo c'est sur que la première méthode est beaucoup plus sûre pour un utilisateur de mon niveau.
Non, c'est pas ça : Si tu refais une réparation des permissions, le problème reviendra. Donc le chmod est livré sous forme d'abonnement.
g = ????????
g = groupe u = user o = others
Tu peux combiner, genre ug+rwx
r = read w = write x = eXecute
On peut aussi atribuer ça sous forme de chiffres, mais ce sera pour une autre fois :)
Ok merci de cette information. En fait je pensai bètement que tout le monde pouvait être sudoer du moment qu'on connait le log et le pass admin.
Tu peux faire un "su toto" où toto est le nom d'un compte admin. ou encore "su" tout court, mais là il faut donner le passwd root, ce qui n'est pas possible par défaut puisque celui ci est désactivé.
Tu peux aussi faire un "sudo visudo" puis modifier la liste des "sudoers" de façon à autoriser toto à faire un sudo, avec ou sans mot de passe.
Finalement c'est mieux comme ça, je pense qu'au niveau sécurité c'est meilleur.
C'est à définir, en fait. Mais je ne vois pas trop l'intérêt d'autoriser un utilisateur à faire un sudo sans lui donner les droits admin, à moins de limiter les droits sudo de cet utilisateur à certaines commandes. Possible également.
-- Nicolas - MICHEL at bluewin point ch AIM : michelnicolas
eric <charpan25@etu.unige.ch> wrote:
Vu ma capacité à faire des boulettes de retranscription, et vu les
conséquances avec un sudo c'est sur que la première méthode est beaucoup
plus sûre pour un utilisateur de mon niveau.
Non, c'est pas ça :
Si tu refais une réparation des permissions, le problème reviendra.
Donc le chmod est livré sous forme d'abonnement.
g = ????????
g = groupe
u = user
o = others
Tu peux combiner, genre ug+rwx
r = read
w = write
x = eXecute
On peut aussi atribuer ça sous forme de chiffres, mais ce sera pour une
autre fois :)
Ok merci de cette information. En fait je pensai bètement que tout le
monde pouvait être sudoer du moment qu'on connait le log et le pass
admin.
Tu peux faire un "su toto" où toto est le nom d'un compte admin.
ou encore "su" tout court, mais là il faut donner le passwd root, ce qui
n'est pas possible par défaut puisque celui ci est désactivé.
Tu peux aussi faire un "sudo visudo" puis modifier la liste des
"sudoers" de façon à autoriser toto à faire un sudo, avec ou sans mot de
passe.
Finalement c'est mieux comme ça, je pense qu'au niveau sécurité
c'est meilleur.
C'est à définir, en fait.
Mais je ne vois pas trop l'intérêt d'autoriser un utilisateur à faire un
sudo sans lui donner les droits admin, à moins de limiter les droits
sudo de cet utilisateur à certaines commandes. Possible également.
--
Nicolas - MICHEL at bluewin point ch
AIM : michelnicolas
Vu ma capacité à faire des boulettes de retranscription, et vu les conséquances avec un sudo c'est sur que la première méthode est beaucoup plus sûre pour un utilisateur de mon niveau.
Non, c'est pas ça : Si tu refais une réparation des permissions, le problème reviendra. Donc le chmod est livré sous forme d'abonnement.
g = ????????
g = groupe u = user o = others
Tu peux combiner, genre ug+rwx
r = read w = write x = eXecute
On peut aussi atribuer ça sous forme de chiffres, mais ce sera pour une autre fois :)
Ok merci de cette information. En fait je pensai bètement que tout le monde pouvait être sudoer du moment qu'on connait le log et le pass admin.
Tu peux faire un "su toto" où toto est le nom d'un compte admin. ou encore "su" tout court, mais là il faut donner le passwd root, ce qui n'est pas possible par défaut puisque celui ci est désactivé.
Tu peux aussi faire un "sudo visudo" puis modifier la liste des "sudoers" de façon à autoriser toto à faire un sudo, avec ou sans mot de passe.
Finalement c'est mieux comme ça, je pense qu'au niveau sécurité c'est meilleur.
C'est à définir, en fait. Mais je ne vois pas trop l'intérêt d'autoriser un utilisateur à faire un sudo sans lui donner les droits admin, à moins de limiter les droits sudo de cet utilisateur à certaines commandes. Possible également.
-- Nicolas - MICHEL at bluewin point ch AIM : michelnicolas
fx [François-Xavier Peretmere]
Un outil que j'utilise pour mes sshd sous Solaris est "denyhost" : http://denyhosts.sourceforge.net/
Je viens de voir qu'il est censé fonctionner sous Mac OS X, mais je n'ai pas encore eu l'occasion de tester, n'ayant de Mac avec ce besoin :
http://denyhosts.sourceforge.net/faq.html#1_16
Un outil que j'utilise pour mes sshd sous Solaris est "denyhost" :
http://denyhosts.sourceforge.net/
Je viens de voir qu'il est censé fonctionner sous Mac OS X, mais je n'ai pas encore
eu l'occasion de tester, n'ayant de Mac avec ce besoin :
Un outil que j'utilise pour mes sshd sous Solaris est "denyhost" : http://denyhosts.sourceforge.net/
Je viens de voir qu'il est censé fonctionner sous Mac OS X, mais je n'ai pas encore eu l'occasion de tester, n'ayant de Mac avec ce besoin :
http://denyhosts.sourceforge.net/faq.html#1_16
eric
eric wrote:
Vu ma capacité à faire des boulettes de retranscription, et vu les conséquances avec un sudo c'est sur que la première méthode est beaucoup plus sûre pour un utilisateur de mon niveau.
Non, c'est pas ça : Si tu refais une réparation des permissions, le problème reviendra. Donc le chmod est livré sous forme d'abonnement.
Je n'ai pas bien compris cette question d'abonnement. Si je fais chmod je modifie de façon "permanente" i.e. qui ne sera pas modifié par le système sauf update de celui-ci, les règles d'accés pour le dit fichier. C'est ça que tu entends par abonnement?
g = ????????
g = groupe u = user o = others
OK merci. Je le note
Tu peux combiner, genre ug+rwx OK ça j'avais compris que les commandes unix sont associables (enfin
certaines) et combinables.
r = read w = write x = eXecute A force de vous lire j'avais fini par comprendre ça, mais c'est toujours
bien de préciser, ne serait-ce que pour les autres lecteurs.
On peut aussi atribuer ça sous forme de chiffres, mais ce sera pour une autre fois :) On va encore attendre un peu que j'ai déjà bien assimilé les points
précédent avant de compliquer avec des chiffres. Mais par curiosité quel est l'intérêt de le faire avec des chiffres plutôt qu'avec des lettres a peu près compréhensible?
Ok merci de cette information. En fait je pensai bètement que tout le monde pouvait être sudoer du moment qu'on connait le log et le pass admin.
Tu peux faire un "su toto" où toto est le nom d'un compte admin. ou encore "su" tout court, mais là il faut donner le passwd root, ce qui n'est pas possible par défaut puisque celui ci est désactivé. La différence entre su et sudo est pour moi parfaitement obscure et
réservée aux initiés.
Tu peux aussi faire un "sudo visudo" puis modifier la liste des "sudoers" de façon à autoriser toto à faire un sudo, avec ou sans mot de passe. D'accord, enfin on va pas trop faire joujou avec les sudo à mon niveau.
C'est à définir, en fait. Mais je ne vois pas trop l'intérêt d'autoriser un utilisateur à faire un sudo sans lui donner les droits admin, à moins de limiter les droits sudo de cet utilisateur à certaines commandes. Possible également.
Donc je continu comme aujourd'hui. Un compte admin pour administrer
l'ordi et faire la maintenance et un compte utilisateur pour le reste du temps. Pas besoin d'être admin pour ce que je fais et au moins je suis sur d'avoir un système a peu près propre. Le seul inconvénient que je vois à mon système c'est que dans des cas comme ici ou j'ai un soucis il faut que jongle entre 2 sessions, mais ce n'est pas insurmontable.
Merci de ces explications.
-- Eric
eric <charpan25@etu.unige.ch> wrote:
Vu ma capacité à faire des boulettes de retranscription, et vu les
conséquances avec un sudo c'est sur que la première méthode est beaucoup
plus sûre pour un utilisateur de mon niveau.
Non, c'est pas ça :
Si tu refais une réparation des permissions, le problème reviendra.
Donc le chmod est livré sous forme d'abonnement.
Je n'ai pas bien compris cette question d'abonnement. Si je fais chmod
je modifie de façon "permanente" i.e. qui ne sera pas modifié par le
système sauf update de celui-ci, les règles d'accés pour le dit fichier.
C'est ça que tu entends par abonnement?
g = ????????
g = groupe
u = user
o = others
OK merci. Je le note
Tu peux combiner, genre ug+rwx
OK ça j'avais compris que les commandes unix sont associables (enfin
certaines) et combinables.
r = read
w = write
x = eXecute
A force de vous lire j'avais fini par comprendre ça, mais c'est toujours
bien de préciser, ne serait-ce que pour les autres lecteurs.
On peut aussi atribuer ça sous forme de chiffres, mais ce sera pour une
autre fois :)
On va encore attendre un peu que j'ai déjà bien assimilé les points
précédent avant de compliquer avec des chiffres. Mais par curiosité quel
est l'intérêt de le faire avec des chiffres plutôt qu'avec des lettres a
peu près compréhensible?
Ok merci de cette information. En fait je pensai bètement que tout le
monde pouvait être sudoer du moment qu'on connait le log et le pass
admin.
Tu peux faire un "su toto" où toto est le nom d'un compte admin.
ou encore "su" tout court, mais là il faut donner le passwd root, ce qui
n'est pas possible par défaut puisque celui ci est désactivé.
La différence entre su et sudo est pour moi parfaitement obscure et
réservée aux initiés.
Tu peux aussi faire un "sudo visudo" puis modifier la liste des
"sudoers" de façon à autoriser toto à faire un sudo, avec ou sans mot de
passe.
D'accord, enfin on va pas trop faire joujou avec les sudo à mon niveau.
C'est à définir, en fait.
Mais je ne vois pas trop l'intérêt d'autoriser un utilisateur à faire un
sudo sans lui donner les droits admin, à moins de limiter les droits
sudo de cet utilisateur à certaines commandes. Possible également.
Donc je continu comme aujourd'hui. Un compte admin pour administrer
l'ordi et faire la maintenance et un compte utilisateur pour le reste du
temps. Pas besoin d'être admin pour ce que je fais et au moins je suis
sur d'avoir un système a peu près propre. Le seul inconvénient que je
vois à mon système c'est que dans des cas comme ici ou j'ai un soucis il
faut que jongle entre 2 sessions, mais ce n'est pas insurmontable.
Vu ma capacité à faire des boulettes de retranscription, et vu les conséquances avec un sudo c'est sur que la première méthode est beaucoup plus sûre pour un utilisateur de mon niveau.
Non, c'est pas ça : Si tu refais une réparation des permissions, le problème reviendra. Donc le chmod est livré sous forme d'abonnement.
Je n'ai pas bien compris cette question d'abonnement. Si je fais chmod je modifie de façon "permanente" i.e. qui ne sera pas modifié par le système sauf update de celui-ci, les règles d'accés pour le dit fichier. C'est ça que tu entends par abonnement?
g = ????????
g = groupe u = user o = others
OK merci. Je le note
Tu peux combiner, genre ug+rwx OK ça j'avais compris que les commandes unix sont associables (enfin
certaines) et combinables.
r = read w = write x = eXecute A force de vous lire j'avais fini par comprendre ça, mais c'est toujours
bien de préciser, ne serait-ce que pour les autres lecteurs.
On peut aussi atribuer ça sous forme de chiffres, mais ce sera pour une autre fois :) On va encore attendre un peu que j'ai déjà bien assimilé les points
précédent avant de compliquer avec des chiffres. Mais par curiosité quel est l'intérêt de le faire avec des chiffres plutôt qu'avec des lettres a peu près compréhensible?
Ok merci de cette information. En fait je pensai bètement que tout le monde pouvait être sudoer du moment qu'on connait le log et le pass admin.
Tu peux faire un "su toto" où toto est le nom d'un compte admin. ou encore "su" tout court, mais là il faut donner le passwd root, ce qui n'est pas possible par défaut puisque celui ci est désactivé. La différence entre su et sudo est pour moi parfaitement obscure et
réservée aux initiés.
Tu peux aussi faire un "sudo visudo" puis modifier la liste des "sudoers" de façon à autoriser toto à faire un sudo, avec ou sans mot de passe. D'accord, enfin on va pas trop faire joujou avec les sudo à mon niveau.
C'est à définir, en fait. Mais je ne vois pas trop l'intérêt d'autoriser un utilisateur à faire un sudo sans lui donner les droits admin, à moins de limiter les droits sudo de cet utilisateur à certaines commandes. Possible également.
Donc je continu comme aujourd'hui. Un compte admin pour administrer
l'ordi et faire la maintenance et un compte utilisateur pour le reste du temps. Pas besoin d'être admin pour ce que je fais et au moins je suis sur d'avoir un système a peu près propre. Le seul inconvénient que je vois à mon système c'est que dans des cas comme ici ou j'ai un soucis il faut que jongle entre 2 sessions, mais ce n'est pas insurmontable.
Merci de ces explications.
-- Eric
Anonyme
eric wrote:
Pour mon information peux tu m'expliquer la commande? Sudo = je prends la main comme root le temps de la commande
Oui
chmod = change mod = changer les propriétés d'un fichier
Oui
g = ????????
Groupe
+r = donne le droit en lecture sur le fichier au niveau g, je suppose /var/log/secure.log = le fichier cible à modifier.
On donne le droit en lecture aux membres du groupe du fichier. Le groupe du fichier dans ce cas étant admin, on donne le droit en lecture aux admins.
-- Anonyme ( jayce <@> mosx.org ) ********* MosX.org <http://www.mosx.org/> ********* (MosX.net renaît sous le nom MosX.org...)
eric <charpan25@etu.unige.ch> wrote:
Pour mon information peux tu m'expliquer la commande?
Sudo = je prends la main comme root le temps de la commande
Oui
chmod = change mod = changer les propriétés d'un fichier
Oui
g = ????????
Groupe
+r = donne le droit en lecture sur le fichier au niveau g, je suppose
/var/log/secure.log = le fichier cible à modifier.
On donne le droit en lecture aux membres du groupe du fichier. Le groupe
du fichier dans ce cas étant admin, on donne le droit en lecture aux
admins.
--
Anonyme ( jayce <@> mosx.org )
********* MosX.org <http://www.mosx.org/> *********
(MosX.net renaît sous le nom MosX.org...)
Pour mon information peux tu m'expliquer la commande? Sudo = je prends la main comme root le temps de la commande
Oui
chmod = change mod = changer les propriétés d'un fichier
Oui
g = ????????
Groupe
+r = donne le droit en lecture sur le fichier au niveau g, je suppose /var/log/secure.log = le fichier cible à modifier.
On donne le droit en lecture aux membres du groupe du fichier. Le groupe du fichier dans ce cas étant admin, on donne le droit en lecture aux admins.
-- Anonyme ( jayce <@> mosx.org ) ********* MosX.org <http://www.mosx.org/> ********* (MosX.net renaît sous le nom MosX.org...)
Anonyme
eric wrote:
Je viens de faire un tour dans /library/receipts/. C'est pas gagné. La réparation des droits ne change rien, ça fait 5 fois que le fais sans modification.
Oui, mais si il s'emmêle entre les différents packages, c'est compréhensible.
Au niveau des receipts, j'ai un peu peur de faire des bétises, je vire que les receipts en rapport avec Mac OS 10.3.x ou il faut aussi virer les security update de cette époque et les composants quicktime de cette époque. Merci de m'éviter de faire une grosse bétise.
De toute façon, ce n'est pas une très grosse bêtise que de virer des fichier Receipts, ils ne servent qu'à : - vérifier quels sont les droits à utiliser dans la réparation des droits. - regarder quels logiciels sont installés pour proposer les bonnes mises à jour automatiquement.
Enfin, tu peux toujours les déplacer dans un autre dossier plutôt que les effacer si tu veux être sûr.
Tu peux virer tous les receipts du 10.3, des security updates et composants systèmes (QT compris) de l'époque.
Finalement le sudo est peut être beaucoup plus facile :-(
Oui, mais ne règlera le problème qu'en apparence. Peut-être (même si je n'y crois pas) que les autres problèmes que tu as sont liés à un problème de droits qui ne serait pas corrigé à cause du même problème que pour secure.log...
-- Anonyme ( jayce <@> mosx.org ) ********* MosX.org <http://www.mosx.org/> ********* (MosX.net renaît sous le nom MosX.org...)
eric <charpan25@etu.unige.ch> wrote:
Je viens de faire un tour dans /library/receipts/.
C'est pas gagné. La réparation des droits ne change rien, ça fait 5 fois
que le fais sans modification.
Oui, mais si il s'emmêle entre les différents packages, c'est
compréhensible.
Au niveau des receipts, j'ai un peu peur
de faire des bétises, je vire que les receipts en rapport avec Mac OS
10.3.x ou il faut aussi virer les security update de cette époque et les
composants quicktime de cette époque. Merci de m'éviter de faire une
grosse bétise.
De toute façon, ce n'est pas une très grosse bêtise que de virer des
fichier Receipts, ils ne servent qu'à :
- vérifier quels sont les droits à utiliser dans la réparation des
droits.
- regarder quels logiciels sont installés pour proposer les bonnes mises
à jour automatiquement.
Enfin, tu peux toujours les déplacer dans un autre dossier plutôt que
les effacer si tu veux être sûr.
Tu peux virer tous les receipts du 10.3, des security updates et
composants systèmes (QT compris) de l'époque.
Finalement le sudo est peut être beaucoup plus facile :-(
Oui, mais ne règlera le problème qu'en apparence.
Peut-être (même si je n'y crois pas) que les autres problèmes que tu as
sont liés à un problème de droits qui ne serait pas corrigé à cause du
même problème que pour secure.log...
--
Anonyme ( jayce <@> mosx.org )
********* MosX.org <http://www.mosx.org/> *********
(MosX.net renaît sous le nom MosX.org...)
Je viens de faire un tour dans /library/receipts/. C'est pas gagné. La réparation des droits ne change rien, ça fait 5 fois que le fais sans modification.
Oui, mais si il s'emmêle entre les différents packages, c'est compréhensible.
Au niveau des receipts, j'ai un peu peur de faire des bétises, je vire que les receipts en rapport avec Mac OS 10.3.x ou il faut aussi virer les security update de cette époque et les composants quicktime de cette époque. Merci de m'éviter de faire une grosse bétise.
De toute façon, ce n'est pas une très grosse bêtise que de virer des fichier Receipts, ils ne servent qu'à : - vérifier quels sont les droits à utiliser dans la réparation des droits. - regarder quels logiciels sont installés pour proposer les bonnes mises à jour automatiquement.
Enfin, tu peux toujours les déplacer dans un autre dossier plutôt que les effacer si tu veux être sûr.
Tu peux virer tous les receipts du 10.3, des security updates et composants systèmes (QT compris) de l'époque.
Finalement le sudo est peut être beaucoup plus facile :-(
Oui, mais ne règlera le problème qu'en apparence. Peut-être (même si je n'y crois pas) que les autres problèmes que tu as sont liés à un problème de droits qui ne serait pas corrigé à cause du même problème que pour secure.log...
-- Anonyme ( jayce <@> mosx.org ) ********* MosX.org <http://www.mosx.org/> ********* (MosX.net renaît sous le nom MosX.org...)
laurent.pertois
Anonyme wrote:
Oui, mais si il s'emmêle entre les différents packages, c'est compréhensible.
Il n'utilise pas tous les packages (heureusement car un package tierce pourrait très bien avoir mis de mauvais droits et le fait de l'utiliser pour réparer les droits ne changerait rien) mais une liste bien précise :
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Anonyme <jayce@mosx.org> wrote:
Oui, mais si il s'emmêle entre les différents packages, c'est
compréhensible.
Il n'utilise pas tous les packages (heureusement car un package tierce
pourrait très bien avoir mis de mauvais droits et le fait de l'utiliser
pour réparer les droits ne changerait rien) mais une liste bien précise
:
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Oui, mais si il s'emmêle entre les différents packages, c'est compréhensible.
Il n'utilise pas tous les packages (heureusement car un package tierce pourrait très bien avoir mis de mauvais droits et le fait de l'utiliser pour réparer les droits ne changerait rien) mais une liste bien précise :
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
eric
Tu peux virer tous les receipts du 10.3, des security updates et composants systèmes (QT compris) de l'époque.
J'ai fait comme tu as dit j'ai viré les receipts (enfin pour le moment ils sont au chaud dans un fichier transitoire avant la poubelle). Je n'ai pas l'impression d'avoir un soucis. Réparation des autorisations, mais ça n'a rien changer. Du coup j'ai fait le sudo et tout roule.
On va voir si ça s'améliore.
Finalement le sudo est peut être beaucoup plus facile :-(
Oui, mais ne règlera le problème qu'en apparence. Peut-être (même si je n'y crois pas) que les autres problèmes que tu as sont liés à un problème de droits qui ne serait pas corrigé à cause du même problème que pour secure.log...
Je vais continuer à jeter un il là dessus et vous tiendrez au courant.
Pour le moment, le point positif en plus, c'est que les applications dashboard se relance automatiquement signe que mon LaunchD va peut être mieux. Je vais quand même vérifier que les scripts périodique se remettent en marche, mais là j'ai quand même plus de doute. Pour info je n'ai jamais modifier la table Cron de ces scripts.
Merci en tout cas de ton aide et des quelques autres qui sont intervenus.
-- Eric
Tu peux virer tous les receipts du 10.3, des security updates et
composants systèmes (QT compris) de l'époque.
J'ai fait comme tu as dit j'ai viré les receipts (enfin pour le moment
ils sont au chaud dans un fichier transitoire avant la poubelle). Je
n'ai pas l'impression d'avoir un soucis. Réparation des autorisations,
mais ça n'a rien changer. Du coup j'ai fait le sudo et tout roule.
On va voir si ça s'améliore.
Finalement le sudo est peut être beaucoup plus facile :-(
Oui, mais ne règlera le problème qu'en apparence.
Peut-être (même si je n'y crois pas) que les autres problèmes que tu as
sont liés à un problème de droits qui ne serait pas corrigé à cause du
même problème que pour secure.log...
Je vais continuer à jeter un il là dessus et vous tiendrez au courant.
Pour le moment, le point positif en plus, c'est que les applications
dashboard se relance automatiquement signe que mon LaunchD va peut être
mieux. Je vais quand même vérifier que les scripts périodique se
remettent en marche, mais là j'ai quand même plus de doute. Pour info je
n'ai jamais modifier la table Cron de ces scripts.
Merci en tout cas de ton aide et des quelques autres qui sont intervenus.
Tu peux virer tous les receipts du 10.3, des security updates et composants systèmes (QT compris) de l'époque.
J'ai fait comme tu as dit j'ai viré les receipts (enfin pour le moment ils sont au chaud dans un fichier transitoire avant la poubelle). Je n'ai pas l'impression d'avoir un soucis. Réparation des autorisations, mais ça n'a rien changer. Du coup j'ai fait le sudo et tout roule.
On va voir si ça s'améliore.
Finalement le sudo est peut être beaucoup plus facile :-(
Oui, mais ne règlera le problème qu'en apparence. Peut-être (même si je n'y crois pas) que les autres problèmes que tu as sont liés à un problème de droits qui ne serait pas corrigé à cause du même problème que pour secure.log...
Je vais continuer à jeter un il là dessus et vous tiendrez au courant.
Pour le moment, le point positif en plus, c'est que les applications dashboard se relance automatiquement signe que mon LaunchD va peut être mieux. Je vais quand même vérifier que les scripts périodique se remettent en marche, mais là j'ai quand même plus de doute. Pour info je n'ai jamais modifier la table Cron de ces scripts.
Merci en tout cas de ton aide et des quelques autres qui sont intervenus.
-- Eric
Nicolas-MICHEL'_remove_'
eric wrote:
Je n'ai pas bien compris cette question d'abonnement. Si je fais chmod je modifie de façon "permanente" i.e. qui ne sera pas modifié par le système sauf update de celui-ci, les règles d'accés pour le dit fichier. C'est ça que tu entends par abonnement?
A chaque réparation des privilèges, tu retrouveras les réglages system
On va encore attendre un peu que j'ai déjà bien assimilé les points précédent avant de compliquer avec des chiffres. Mais par curiosité quel est l'intérêt de le faire avec des chiffres plutôt qu'avec des lettres a peu près compréhensible?
Une fois que tu as compris le système, les chiffres ne sont pas plus compliqués que les lettres.
Avec les lettres, tu t'exprime en ajoutant ou en soustrayant des permissions à ce qui est existant. Avec les chiffres, tu donnes le résultat final. Donc avec les chiffres, tu n'as pas besoins de connaitre l'état actuel des permissions, tu dis juste ce que tu veux.
C'est deux façon différentes et complémentaires de spécifier ce que tu veux.
La différence entre su et sudo est pour moi parfaitement obscure et réservée aux initiés.
Avec un "su toto" tu prends l'identité de toto en donnant le passwd de toto. Avec "sudo -s -u toto" tu prends aussi l'identité de toto mais en entrant ton propre mot de passe.
Donc par exemple "su root" n'est possible que si root est activé, puisque sinon root n'a pas de passwd. Tandisqu'avec "sudo -s -u root" tu donne ton propre passwd et tu peux le faire même si root est désactivé.
C'est donc très similaire, sauf que avec sudo tu n'as qu'un seul mot de passe à connaitre, le tien.
-- Nicolas - MICHEL at bluewin point ch AIM : michelnicolas
eric <charpan25@etu.unige.ch> wrote:
Je n'ai pas bien compris cette question d'abonnement. Si je fais chmod
je modifie de façon "permanente" i.e. qui ne sera pas modifié par le
système sauf update de celui-ci, les règles d'accés pour le dit fichier.
C'est ça que tu entends par abonnement?
A chaque réparation des privilèges, tu retrouveras les réglages system
On va encore attendre un peu que j'ai déjà bien assimilé les points
précédent avant de compliquer avec des chiffres. Mais par curiosité quel
est l'intérêt de le faire avec des chiffres plutôt qu'avec des lettres a
peu près compréhensible?
Une fois que tu as compris le système, les chiffres ne sont pas plus
compliqués que les lettres.
Avec les lettres, tu t'exprime en ajoutant ou en soustrayant des
permissions à ce qui est existant. Avec les chiffres, tu donnes le
résultat final. Donc avec les chiffres, tu n'as pas besoins de connaitre
l'état actuel des permissions, tu dis juste ce que tu veux.
C'est deux façon différentes et complémentaires de spécifier ce que tu
veux.
La différence entre su et sudo est pour moi parfaitement obscure et
réservée aux initiés.
Avec un "su toto" tu prends l'identité de toto en donnant le passwd de
toto.
Avec "sudo -s -u toto" tu prends aussi l'identité de toto mais en
entrant ton propre mot de passe.
Donc par exemple "su root" n'est possible que si root est activé,
puisque sinon root n'a pas de passwd. Tandisqu'avec "sudo -s -u root" tu
donne ton propre passwd et tu peux le faire même si root est désactivé.
C'est donc très similaire, sauf que avec sudo tu n'as qu'un seul mot de
passe à connaitre, le tien.
--
Nicolas - MICHEL at bluewin point ch
AIM : michelnicolas
Je n'ai pas bien compris cette question d'abonnement. Si je fais chmod je modifie de façon "permanente" i.e. qui ne sera pas modifié par le système sauf update de celui-ci, les règles d'accés pour le dit fichier. C'est ça que tu entends par abonnement?
A chaque réparation des privilèges, tu retrouveras les réglages system
On va encore attendre un peu que j'ai déjà bien assimilé les points précédent avant de compliquer avec des chiffres. Mais par curiosité quel est l'intérêt de le faire avec des chiffres plutôt qu'avec des lettres a peu près compréhensible?
Une fois que tu as compris le système, les chiffres ne sont pas plus compliqués que les lettres.
Avec les lettres, tu t'exprime en ajoutant ou en soustrayant des permissions à ce qui est existant. Avec les chiffres, tu donnes le résultat final. Donc avec les chiffres, tu n'as pas besoins de connaitre l'état actuel des permissions, tu dis juste ce que tu veux.
C'est deux façon différentes et complémentaires de spécifier ce que tu veux.
La différence entre su et sudo est pour moi parfaitement obscure et réservée aux initiés.
Avec un "su toto" tu prends l'identité de toto en donnant le passwd de toto. Avec "sudo -s -u toto" tu prends aussi l'identité de toto mais en entrant ton propre mot de passe.
Donc par exemple "su root" n'est possible que si root est activé, puisque sinon root n'a pas de passwd. Tandisqu'avec "sudo -s -u root" tu donne ton propre passwd et tu peux le faire même si root est désactivé.
C'est donc très similaire, sauf que avec sudo tu n'as qu'un seul mot de passe à connaitre, le tien.
-- Nicolas - MICHEL at bluewin point ch AIM : michelnicolas
