On Mon, Feb 12, 2007 at 12:27:46PM -0500, David Zeuthen wrote: > desktop session is defined by knowledge of this secret. So we can get > the process id of the caller and from there ConsoleKit (running with > sufficient privileges) can look up into /proc for that process and peek > at what XDG_SESSION_COOKIE is set to. Yuk. Thats not very clever. Environment is private to the program and that means that poking around in /proc won't always give you the current environment of the program and that it can set itself up so you get a different answer to the one you expect. > point. E.g. if we could securely tag a process with a cookie and ensure > that it's inherited by child processes and said child processes cannot > change it we're good. And then we can use this mechanism instead of the > rather ugly way of using environment variables. Unfortunately, to my > knowledge at least, the Linux kernel don't yet support something like > this. That would be because such a restriction is meaningless and has no relevance to the security model. Security is enforced by user id and not by session (ok SELinux is a bit more complex). Our unix socket interface even allows you to do credential passing. Perhaps if you can explain your actual security model someone can provide an implementation but I don't currently understand your model even. If I've got a desktop session with some "right" to shut down the system and a remote session I can shut down the box remotely, you can't stop me as I can set up apps in one to listen to the other. If you are trying to do distributed secrets based authentication of services and access rights then its called kerberos and the libraries are installed. Alan -- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers -- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
