Re: GNOME privilege library
- From: Sean Middleditch <elanthis awesomeplay com>
- To: Colin Walters <walters redhat com>
- Cc: Desktop Devel <desktop-devel-list gnome org>
- Subject: Re: GNOME privilege library
- Date: Thu, 13 Jan 2005 16:01:14 -0500
On Thu, 2005-01-13 at 15:25 -0500, Colin Walters wrote:
> > - applications can start and stop the backend process at any time
>
> Not sure I see how this is particularly useful.
Let us say I start procman. If I'm just using its basic features, I
don't need the elevated privileges, so there's no reason at all to ask
for authentication. Only at the point when I want to use a feature like
renice should I be rquired to authenticate. It's thus at least
important to be able to start the backend after the app starts, as in
many cases the backend might not be needed. Stopping the backend might
not be all that important, but I can imagine for long-running
applications it could be nice to shut down the backend when not in use
and start it back up again later (which may, or may not, require re-
authentication, depending on the backend and settings the administrator
chose).
>
> > - API provides clean and safe abstraction over starting and
> > communicating with the backend process
>
> D-BUS :)
Everyone keeps jumping to the implementation details. ~_^
>
> > - API does not make *any* assumptions about authentication system in
> > use on the system
>
> The approach we've been taking in Fedora is that the user is just not
> prompted for authentication. For example, NetworkManager doesn't force
> you to enter the root password to switch wireless networks. Nor does
> HAL force you to enter the root password to access your USB key. As
> Havoc mentioned earlier, I think this is generally the right approach.
But there are cases where it is the right approach. For some use cases
you want transparent ease of use. In other cases you don't.
The method you use in Fedora is perfectly acceptable to this proposal.
Your libgnome-priv-auth-foo-blah would simply not prompt for
authentication for those tasks. On Super Sensational Security Linux for
Pentagon Officials distribution, they might want slightly different
controls - and by using a clean API, they can do that without recoding
anything but the privilege library.
>
> > - API is pro-active on security by only allowing certain applications
> > to use certain backend
>
> Let's write this one off as not solvable for now.
That's fine. Again, that feature could be added later without changing
applications if everything is abstracted through the API properly.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]