Nieuws:

Welkom, Gast. Alsjeblieft inloggen of registreren.
Heb je de activerings-mail niet ontvangen?

Auteur Topic: Systeem>Beheer>Authorizations>Policykit  (gelezen 3152 keer)

URob

  • Gast
Systeem>Beheer>Authorizations>Policykit
« Gepost op: 2009/01/13, 21:11:51 »
Help!

Onder de policykit staat:
- Revoke authorizations from other users
- Read authorizations of other users
- Modify defaults
- Grant authorizations

Bij alle vier zijn de instellingen -> Implicit authorizations: Anyone=No, Console=No, Active console=No

Ik kan de instellingen niet terug veranderen naar Avtive console = Admin authentification

Hoe kan ik de default instellingen terug krijgen ?

"Revert to defaults" staat grijs en wanneer ik de button "Edit..." wil gebruiken dan is daarin de "Modify..." button eveneens grijs

Nochtans ben ik ingelogd als user met gebruikersrechten "Mag het systeem beheren" aangevinkt.

Re: Systeem>Beheer>Authorizations>Policykit
« Reactie #1 Gepost op: 2009/01/14, 10:22:35 »
Bij alle vier zijn de instellingen -> Implicit authorizations: Anyone=No, Console=No, Active console=No

Ik kan de instellingen niet terug veranderen naar Avtive console = Admin authentification

Hoe kan ik de default instellingen terug krijgen ?

"Revert to defaults" staat grijs en wanneer ik de button "Edit..." wil gebruiken dan is daarin de "Modify..." button eveneens grijs

Nochtans ben ik ingelogd als user met gebruikersrechten "Mag het systeem beheren" aangevinkt.
Oeps, sorry, niet goed gelezen ;)
« Laatst bewerkt op: 2009/01/14, 10:25:06 door AutoStatic »

Re: Systeem>Beheer>Authorizations>Policykit
« Reactie #2 Gepost op: 2009/01/14, 16:52:39 »
Ben niet zo bekend hiermee, maar heb je hier al gekeken? http://hal.freedesktop.org/docs/PolicyKit/

Met vriendelijke groet,

Gijs
In der Beschränkung zeigt sich der Meister.

URob

  • Gast
Re: Systeem>Beheer>Authorizations>Policykit
« Reactie #3 Gepost op: 2009/01/14, 20:12:33 »
Ben niet zo bekend hiermee, maar heb je hier al gekeken? http://hal.freedesktop.org/docs/PolicyKit/

Met vriendelijke groet,

Gijs

Bedankt voor reactie.
Dit is de eerste link waar ik ben gaan kijken, maar moet toegeven dat de uitleg voor mij veel te technisch is.
Kan het zijn dat het om een bug gaat?

mvg

Re: Systeem>Beheer>Authorizations>Policykit
« Reactie #4 Gepost op: 2009/01/14, 21:31:35 »
URob, wat is de uitkomst van cat /etc/PolicyKit/PolicyKit.conf in een terminal? Kopiëren gaat met shift+ctrl+c vanuit de terminal.

Re: Systeem>Beheer>Authorizations>Policykit
« Reactie #5 Gepost op: 2009/01/14, 21:33:07 »
Ik had nog een edit er bij getypt, ik denk vergeten op verzenden te drukken. :(
Als je het programma zo opent in de terminal gksudo polkit-gnome-authorization kan je dan wel de Edit knop gebruiken?

Met vriendelijke groet,

Gijs
In der Beschränkung zeigt sich der Meister.

URob

  • Gast
Re: Systeem>Beheer>Authorizations>Policykit
« Reactie #6 Gepost op: 2009/01/15, 17:09:31 »
Gijs,

YES !!!
Dat was de oplossing.
Vervolgens 'revert to defaults' knop gebruikt die nu wel werkte en alles weer in orde.

 :) :) :) :) :) :) :) :)

Met "DANKENDE" groet

Rob

Offline Ploffie

  • Lid
Re: Systeem>Beheer>Authorizations>Policykit
« Reactie #7 Gepost op: 2010/04/02, 10:46:35 »
Wat doet die 'Policykit' want deze vreet bij mij nu continu bijna 100% van de processorkracht op?
Desktop en Kleptop voorzien van 10.04.1...dusss...

˙doʞ uɾız do ʇɐɐʇs pʃǝɹǝʍ ǝʃǝɥ ǝ◖

Re: Systeem>Beheer>Authorizations>Policykit
« Reactie #8 Gepost op: 2010/04/02, 14:01:19 »
Wat doet die 'Policykit' want deze vreet bij mij nu continu bijna 100% van de processorkracht op?
Citaat van: de ontwikkelaars
About

PolicyKit is a toolkit for defining and handling the policy that allows unprivileged processes to speak to privileged processes: It is a framework for centralizing the decision making process with respect to granting access to privileged operations for unprivileged applications. PolicyKit is specifically targeting applications in rich desktop environments on multi-user UNIX-like operating systems.

History and Prior Art

Traditionally UNIX-like operating systems have a clear distinction between ordinary unprivileged users and the almight and powerful super user 'root'. However, in order for a user to access and configure hardware additional privileges and rights are needed. Hitherto, this have been done in a number of often OS-specific ways. For example, Red Hat based systems usually grant access to devices to a user if, and only if, the user is logged in at a local console. In contrast, Debian-based systems often relies on group membership, e.g. users in the 'cdrom' group can access optical drives, users in the 'plugdev' group can mount removable media and so on.

In addition, access was not only granted to devices; Red Hat-based systems, for example, provides a mechanism to allow a user at a local system to run certain applications (such as the system-config-* family) as the super user provided they could authenticate as the super user (typically by entering the root password using a graphical utility). Other distributions rely on sudo (with various graphical frontends) to provide similar functionality. Both the pam-console and sudo approaches doesn't require applications to be modified.

Finally, some classes of software (such as HAL, NetworkManager and gnome-system-tools) utilizes IPC mechanism (typically D-Bus) to provide a very narrow and well-defined subset of privileged operations to unprivileged desktop applications. It varies what mechanism is used to deny users.
Defining the Problem

There's a couple of problems with the status quo

    *

      Mechanisms are coarsely grained: either you're at the console or you're not (pam_console). Either you're a member of a group or you're not (Debian). There is no easy way to specify that only a subset of privileged operations should be available for a given user (e.g. it's hard to express "it's fine to mount removable media; it's not fine to mount fixed media; it's not fine to change the timezone" in a coherent way).
    *

      The way most people use pam-console and sudo is fundamentally broken. Full-fledged GTK+ or Qt applications as the super user which means that millions of line of code (including code such as image loaders that historically have lots of security problems) runs privileged. This is in direct violation of the well-known "least privilege" principle. In addition, often applications look out of place because settings in such programs now read per-user settings from root's home directory.
    *

      UNIX group membership have always been problematic; if a user is a member of a group once, he can always become member of the group again (copy /bin/bash to $HOME; chown to group, set the setgid bit, done).
    *

      It is difficult for upstream projects (such as GNOME or KDE) to implement features that requires administrative privileges because most downstream consumers (e.g. operating systems) have different ways of implementing access control. As a result most of these features are punted to OS distributors who have their own code for doing the same thing e.g. setting the date/timezone etc.; there is no way for file sharing applications (such as gnome-user-share, Banshee, Rhythmbox) to punch a hole in the firewall.
    *

      Without a centralized framework, access control configuration is often scattered throughout the system which makes it hard for system administrators to grasp how to configure the system.

Meer: http://people.freedesktop.org/~david/polkit-spec.html
En de Google vertaling, je kan beter een woordenboek bij pakken. XD
Over

PolicyKit is een toolkit voor het bepalen en hanteren het beleid dat toestaat onbevoegde processen aan te spreken bevoorrechte processen: Het is een kader voor de centralisatie van de besluitvorming met betrekking tot het verlenen van toegang tot bijzondere activiteiten voor onbevoegde toepassingen. PolicyKit is specifiek gericht op toepassingen in de rijke desktop omgevingen op multi-user UNIX-achtige besturingssystemen.

Geschiedenis en Kunst Voorafgaande

Traditioneel UNIX-achtige besturingssystemen hebben een duidelijk onderscheid tussen gewone onbevoegde gebruikers en de almacht en krachtige super user 'root'. Echter, om voor een gebruiker om toegang te krijgen en te configureren hardware bijkomende voorrechten en rechten nodig zijn. Tot nu toe hebben dit gedaan in een aantal vaak besturingssysteem-specifieke manieren. Bijvoorbeeld, op Red Hat gebaseerde systemen gewoonlijk toegang te verlenen tot hulpmiddelen aan een gebruiker als en slechts als de gebruiker is ingelogd op een lokale console. In tegenstelling, Debian-gebaseerde systemen berust vaak op lidmaatschap van een groep, bijv. gebruikers in de 'cdrom' groep kan de toegang optische drives, gebruikers in de 'plugdev' groep kan mounten verwisselbare media en ga zo maar door.

Bovendien, werd de toegang niet alleen toegekend aan apparaten; Red Hat gebaseerde systemen, bijvoorbeeld, biedt een mechanisme om een gebruiker toe op een lokaal systeem voor bepaalde toepassingen (zoals de system-config-* familiehotel) als de super user op voorwaarde dat zij kan worden geverifieerd als de super user (meestal door het invoeren van het root-wachtwoord met behulp van een grafische utility). Andere distributies beroepen op sudo (met verschillende grafische frontends) tot en met vergelijkbare functionaliteit bieden. Zowel de pam-console en sudo aanpak vereist niet dat de aanvragen worden gewijzigd.

Tot slot, sommige klassen van software (zoals HAL, NetworkManager en gnome-system-tools) maakt gebruik van IPC mechanisme (meestal D-Bus) een zeer smal en goed gedefinieerde deelverzameling van bevoorrechte operaties te verlenen aan onbevoegde desktop applicaties. Het varieert welk mechanisme wordt gebruikt om gebruikers te weigeren.
Definitie van het probleem

Er zijn een paar van de problemen met de status quo

    *

      Mechanismen zijn grofkorrelig: ofwel ben je op de console of u bent niet (pam_console). Of je bent een lid van een groep of je bent het niet (Debian). Er is geen makkelijke manier om aan te geven dat slechts een subset van de bevoorrechte operaties moeten beschikbaar zijn voor een bepaalde gebruiker (bijv. het is moeilijk uit te drukken "het prima is te monteren verwisselbare media, het is niet fijn te monteren vaste media, het is niet fijn om te veranderen van de tijdzone "op een coherente manier).
    *

      De manier waarop de meeste mensen gebruiken pam-console en sudo is fundamenteel gebroken. Volwaardige GTK + of Qt applicaties als de super user, wat betekent dat miljoenen regel code (inclusief code zoals beeld-laders die in het verleden hebben veel problemen van veiligheid) loopt bevoorrecht. Dit is een rechtstreekse schending van de bekende "Least Privilege"-principe. Bovendien, vaak toepassingen misstaan, omdat instellingen in deze programma's nu te lezen per gebruiker instellingen uit binnen-root directory.
    *

      UNIX-lidmaatschap van een groep zijn altijd problematisch geweest, als een gebruiker is een lid van een groep eens is, kan hij altijd opnieuw lid geworden van de groep (copy / bin / bash $ HOME; chown aan de groep, stelt u de setgid bit, gedaan).
    *

      Het is moeilijk voor upstream-projecten (zoals GNOME of KDE) om functies die beheerdersrechten vereist voeren, omdat de meeste consumenten downstream (bijv. besturingssystemen) hebben verschillende manieren om de uitvoering van controle op de toegang. Als gevolg de meeste van deze functies zijn punted naar OS distributeurs die hun eigen code hebben voor hetzelfde te doen bv vaststelling van de datum / tijdzone, enz., er is geen manier voor file sharing applicaties (zoals gnome-user-share, Banshee, Rhythmbox) om een gat in de firewall punch.
    *

      Zonder een gecentraliseerde kader, controle op de toegang configuratie wordt vaak verspreid door het hele systeem dat maakt het moeilijk voor systeembeheerders om te begrijpen hoe het systeem te configureren.

Meer: http://people.freedesktop.org/ ~ david / polkit-spec.html

« Laatst bewerkt op: 2010/04/02, 14:03:00 door Gijsbert »
In der Beschränkung zeigt sich der Meister.

Offline Ploffie

  • Lid
Re: Systeem>Beheer>Authorizations>Policykit
« Reactie #9 Gepost op: 2010/04/02, 14:08:26 »
Grappige is dat als ik bij systeemmonitor kijk alles op bijna op 0% CPU staat, maar bij htop heeft policykit teveel speed gebruikt ofzo...
Desktop en Kleptop voorzien van 10.04.1...dusss...

˙doʞ uɾız do ʇɐɐʇs pʃǝɹǝʍ ǝʃǝɥ ǝ◖

Re: Systeem>Beheer>Authorizations>Policykit
« Reactie #10 Gepost op: 2010/04/02, 14:16:32 »
Of htop, als de Policykit 100% in beslag neemt van je CPU schiet het niet op. XD
Interpreteer je de gegevens wel goed, je bent toch niet in dat afbraak pand geweest ???  :o :o :o
Plaats eens van beide een knap plaatje, ik wil dit mirakel wel aanschouwen.  :rolleyes:
In der Beschränkung zeigt sich der Meister.

Offline Ploffie

  • Lid
Re: Systeem>Beheer>Authorizations>Policykit
« Reactie #11 Gepost op: 2010/04/02, 14:22:20 »
Als jij niet in dat pand bent geweest had je dit wel gevonden...

http://forum.ubuntu-nl.org/test-forum/ubuntu-10-04-lucid-lynx/1650/

Desktop en Kleptop voorzien van 10.04.1...dusss...

˙doʞ uɾız do ʇɐɐʇs pʃǝɹǝʍ ǝʃǝɥ ǝ◖

Re: Systeem>Beheer>Authorizations>Policykit
« Reactie #12 Gepost op: 2010/04/02, 16:28:13 »
Daar heb ik zelf ook wat getypt. Maar wat is er mee? Doel je hier op? Plymouth?
Ik ben vaak genoeg in dat pand geweest, alleen kreeg ik daar geen whiskey. Waar ik op doelde, je hebt daar toch geen t*** gedronken? En anders, waar ben je in Godsnaam mee bezig?
In der Beschränkung zeigt sich der Meister.

Offline Ploffie

  • Lid
Re: Systeem>Beheer>Authorizations>Policykit
« Reactie #13 Gepost op: 2010/04/02, 19:22:07 »
Dat wil je niet weten...
Desktop en Kleptop voorzien van 10.04.1...dusss...

˙doʞ uɾız do ʇɐɐʇs pʃǝɹǝʍ ǝʃǝɥ ǝ◖

Re: Systeem>Beheer>Authorizations>Policykit
« Reactie #14 Gepost op: 2010/04/02, 19:25:55 »
Vertel.. :rolleyes: Ik ben niet nieuwsgierig, ik wil wel graag alles weten. XD
Ik type dit nu in 10.4 Beta, waarom heb ik die leuke problemen nooit  ???
In der Beschränkung zeigt sich der Meister.

Offline Ploffie

  • Lid
Re: Systeem>Beheer>Authorizations>Policykit
« Reactie #15 Gepost op: 2010/04/02, 20:06:47 »
Ach, de processor verbrande bijna zonder dat er een programma openstond.
Heb nu Karmic teruggezet, krijg alleen de grub niet lekker voor elkaar, ik heb Karmic over Lynx heen gezet maar die nieuwste kernels blijven in de grub staan.

De startupmanager luistert ook niet goed, de kernel die ik daar instel wordt niet gekozen tijdens de opstart...raarrrr
Desktop en Kleptop voorzien van 10.04.1...dusss...

˙doʞ uɾız do ʇɐɐʇs pʃǝɹǝʍ ǝʃǝɥ ǝ◖

Re: Systeem>Beheer>Authorizations>Policykit
« Reactie #16 Gepost op: 2010/04/02, 20:13:30 »
Kunnen we daarmee verder gaan in het draadje voor 10.04? Bedankt :).

Re: Systeem>Beheer>Authorizations>Policykit
« Reactie #17 Gepost op: 2010/04/02, 20:14:47 »
Ploffie antwoord verplaatst naar 10.4 topic.
« Laatst bewerkt op: 2010/04/02, 20:16:57 door Gijsbert »
In der Beschränkung zeigt sich der Meister.

Offline Ploffie

  • Lid
Re: Systeem>Beheer>Authorizations>Policykit
« Reactie #18 Gepost op: 2010/04/02, 20:44:03 »
Kunnen we daarmee verder gaan in het draadje voor 10.04? Bedankt :).

Tuurlijks.
Desktop en Kleptop voorzien van 10.04.1...dusss...

˙doʞ uɾız do ʇɐɐʇs pʃǝɹǝʍ ǝʃǝɥ ǝ◖