Re: root login
On Mon, Apr 28, 2003 at 02:20:41AM +1000, Jeff Waugh wrote:
> <quote who="Sven Luther">
>
> > But that said, isn't the unix groups exactly such a permission granting
> > system ?
>
> No, we're talking about permission elevation here - systems like su and
> sudo, with pam support are examples of this on our platform.
That is the solution you propose to the problem. There may be other ways
to solve the problems though, which don't involve permission elevation,
like the gdm message passing you really don't even like to talk about,
or using groups.
That said, ...
> > Well, the message was about getting some response from the session on what
> > to do afterward, or getting some error code result from X or something
> > such, i don't remember exactly.
>
> The original poster wondered why GDM wouldn't allow him to log in as root.
Yes, and was replied you should not use gnome as root, and i created a
diversion of the thread by saying that there are currently some stuff
that needs to be root. Among them are launching configuration apps and
shuting down. Maybe i should have changed the subject or something such ?
> > But ok, let's focus on the primary issue, which is threefold :
> >
> > o a way to allow trusted users to run root-privilege configuration
> > stuff (gdm configurator, package manager frontends, etc.)
> >
> > o a way to allow a passing administrator to launch the same root
> > privilege stuff without without login out, by just entering the root
> > password.
> >
> > o a way to allow trusted users to shutdown or reboot the box.
>
> The first and third are just capabilities provided by the second (though,
> the second may not involve becoming root at all, it may just be a method of
> providing temporary permissions elevation).
Mmm, yes, in a sense, but at least the first can also be solved in ways
different from the second, especially by modifying the apps so that you
don't need to be root to use them. You would thus need to have a
temporary permission elevation all the way to root, but a more limited
permission elevation, to a specific group, but which would not need to
be temporary.
> > > Can you see that these statements do not work well together? Sorry, but if
> > > don't understand the security/portability issues, nor want to find out about
> > > them, you're not actually saying anything useful. What you have said not
> > > correct (it is not a simple issue).
> >
> > Well, in gnome 1 i could shutdown with one click from the gnome session
> > using a sudo gshutdown launcher button, something i cannot do anymore.
> > Why was gshutdown removed ?
>
> No idea.
I guess it is because very little person used it, and because the gnome
maintainers felt that it was duplication of code with the logout
functionality. After all the gshutdown code was maintained totally apart
from the logout code.
In this way i understand that it was removed, but it was not re-added
the right way, and since redhat has its own hack/patch/fork/whatever
nobody thinks it is an important thing to work on.
> > I think i understand the security issues, at least somewhat, what i was
> > saying is i don't understand the ones you are specially speaking about,
> > and the portability issues ? Do you mean arch portability or underlying
> > OS portability ? Or something else ?
>
> OS, and the security issues are code and protocol related, not user issues.
So, which OS are gnome targets which don't have groups ? And is it
planed to release a windows version of gnome ?
And anyway, by saying that gnome should not be run as gnome, you clearly
state that it is not secure enough for it, which is only normal. There
is no way you can obtain secure C code anyway, that is without using
some code proving framework, like B for example, or a secure language.
But this is not in the gnome culture, and security is obtained, by many
scrutating eyes and quick reactive speed to discovered problems.
> > > A general solution, which this is not, is not that simple. And without a
> > > general solution, you haven't solved much.
> >
> > Ok, let me see if i understood you well.
> >
> > I guess the group thingy is not portable because it will work only on unix
> > systems, and not on non-group systems, right ?
>
> > Now, it does cause a problem if you plan to run on an OS that is not Group
> > aware. But i am not aware of gnome running on such an OS.
>
> This has nothing to do with groups. It's about permissions elevation and
> capabilities. I really strongly suggest that you read about the various *-su
> solutions posted to desktop-devel-list a while back, and the discussion that
I don't follow this list, so it seem normal that i don't know about it,
any url to the mail archive of it ?
> ensued. I'm still not sure you know what you're talking about, sorry.
Well, i don't really know what there is to understand, or rather what
you think i don't understand. In traditional unix systems, there are
user, group and world permission, as well as setuid. You can then either
use this system to grant a specific user specific right accordying to a
group or something, as this is done for the audio access on debian for
example, or use sudo or something such to give permission elevation.
Using group can be seen as a less drastic but permanent permission
elevation, while sudo or su is temporary but more drastic way of
achieving the same goal. In all this discussion, you have been focusing
more on the temporary permission elevation, and totally ignoring the
group way of doing things, probably because it is not portable to other
OSes, but still, you start from an a priori i have no way of having
knowledge of, so accusing me of having no idea what i am talking about
when i have just no idea on what you already decided would be the right
solution seems a bit rude to me.
That said, maybe i am only speaking bullshit and really have no idea of
what i speak about, in this case please tell me, but please also tell me
it more specificly. I had also the impression that maybe we were not
speaking about the same thing exactly.
Friendly,
Sven Luther
Reply to: