Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

[Q] Cocher "ignorer les permissions" sans droits.

4 réponses
Avatar
blanc
Bonjour à tous,

Je viens de suivre avec intérêt le fil initié à ce sujet par Mr Wrong.

J'y ai fait une remarque que je remets ici sous forme de question :

Personnellement j'ai constaté chez moi, qu'un utilisateur non admin
pouvait recocher la case "ignorer les permissons" d'un volume (externe)
sans avoir besoin de taper aucun mot de passe ;-(

Suis-je le seul dans ce cas ?

Par contre il faut un mot de passe pour décocher cette case.

Et en tant qu'admin il faut utiliser sudo si on veut cocher/décocher
cette case avec vsdbutil.

Alors je ne comprends pas bien la logique de la chose. Si n'importe qui
peut cocher la case, quelle protection apporte-t-elle ?


--
JiPaul.
/ /--/--//\\ Jean-Paul Blanc
|/| L |\\\ quelquepart en (somewhere in)
\/|| = |||\\\ FRANCE

4 réponses

Avatar
blanc
Patrick Stadelmann wrote:

Commencer par vérifier que les permissions reflètent bien l'état de la
case !


Oui, oui, j'ai bien sûr vèrifié ça. Quand la case est cochée, les
permissions sont effectivement inactives.

Ensuite, il me semble (mais à vérifier) que le comportement est
différent si le disque a est monté par le système (il est assimilé à un
disque interne, et ne peut être démonté sans autorisation). Si le disque
est monté par l'utilisateur, la sécurité n'est de toute façon pas là :
il peut le monter sur une autre machine qui par défaut ignorera les
permissions.


Disque monté par le système dans mon cas.

--
JiPaul.
/ /--/--// Jean-Paul Blanc
|/| L | quelquepart en (somewhere in)
/|| = ||| FRANCE

Avatar
Patrick Stadelmann
In article <1i3zj4i.u8xxl0141y97gN%,
(JiPaul) wrote:

Patrick Stadelmann wrote:

Ensuite, il me semble (mais à vérifier) que le comportement est
différent si le disque a est monté par le système (il est assimilé à un
disque interne, et ne peut être démonté sans autorisation). Si le disque
est monté par l'utilisateur, la sécurité n'est de toute façon pas là :
il peut le monter sur une autre machine qui par défaut ignorera les
permissions.


Disque monté par le système dans mon cas.


Je viens de tester en 10.4.10 : disque externe monté via "sudo mount" en
ssh alors qu'aucune session graphique n'est ouverte. Auparavant, j'avais
décoché la case, attribué la racine du volume a root:wheel et restreint
l'accès en écriture à la racine à root.

Ensuite, quand j'ouvre une session graphique non-admin, je ne peux pas
démonter le disque. Je peux cocher la case, mais les permissions restent
actives (confirmé par vsdbutil). Refermer et rouvrir la fenêtre d'infos
suffit à ce que la case soit à nouveau décochée.

Pour que ce comportement soit automatique, il faut je suppose configurer
la machine pour que le disque externe soit monté pendant le boot (via
fstab ?), et non au login comme c'est le cas par défaut.

Patrick
--
Patrick Stadelmann


Avatar
blanc
Patrick Stadelmann wrote:

Je viens de tester en 10.4.10 : disque externe monté via "sudo mount" en
ssh alors qu'aucune session graphique n'est ouverte. Auparavant, j'avais
décoché la case, attribué la racine du volume a root:wheel et restreint
l'accès en écriture à la racine à root.


Chez moi 10.4.10 sur G4 Quicksilver, montage automatique par le système
au login (ou à l'ouverture de session ?). La case est décochée. La
racine du volume appartient à root:admin. L'accès écriture est à u et g.
Si je coche la case, la racine du volume semble m'apartenir, ce qui est
normal. Et si je la décoche, ça revient à root:admin.


Ensuite, quand j'ouvre une session graphique non-admin, je ne peux pas
démonter le disque. Je peux cocher la case, mais les permissions restent
actives (confirmé par vsdbutil). Refermer et rouvrir la fenêtre d'infos
suffit à ce que la case soit à nouveau décochée.


Quand j'ouvre une session admin, le disque semble d'abord non monté,
puis apparaît au bout de quelques secondes. Je peux le démonter et le
remonter comme je veux.

Je peux cocher la case et les permissions deviennent inactives : je peux
alors accéder à un dossier qui est normalement protégé. Et vsdbutil
m'annonce que les protections sont inactives.

Si je décoche ensuite, il faut que je tape un mot de passe admin, et le
dossier dont je parle est de nouveau protégé. Et vsdbutil m'annonce que
les p sont actives.


Je viens de changer les protections de la racine pour que ce soit les
mêmes que toi : root:wheel et écriture par root uniquement. Ca ne change
rien.

Pour que ce comportement soit automatique, il faut je suppose configurer
la machine pour que le disque externe soit monté pendant le boot (via
fstab ?), et non au login comme c'est le cas par défaut.


Peut-être, mais ce n'est quand même pas normal que dans le comportement
par défaut, on puisse enlever la protection si facilement.

Ceci étant je veux bien tester avec un montage au boot. Mais je ne l'ai
jamais fait. Peux-tu m'indiquer la marche à suivre ?

--
JiPaul.
/ /--/--// Jean-Paul Blanc
|/| L | quelquepart en (somewhere in)
/|| = ||| FRANCE

Avatar
Patrick Stadelmann
In article <1i40fv6.14meq81g46lpgN%,
(JiPaul) wrote:

Ceci étant je veux bien tester avec un montage au boot. Mais je ne l'ai
jamais fait. Peux-tu m'indiquer la marche à suivre ?


Moi non plus, je ne sais pas d'ailleurs comment le faire exactement
(mais d'autres sur le groupe devraient pouvoir répondre). J'ai juste
simulé cette situation en montant le disque sans qu'aucune session ne
soit ouverte (via ssh donc), afin qu'il se comporte comme un disque
interne (non démontable par un utilisateur standard).

Je pense que la différence vient de là. Si le disque est monté au login
(il apparaît quelques secondes après les autres, comme tu l'as observé),
il est démontable par l'utilisateur et le système semble considérer
qu'il n'y a pas lieu de le protéger.

Patrick
--
Patrick Stadelmann