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
