Dominique and I discussed the underlying problem in some detail and believe that we have a cleaner solution.
The plan is to have one launcher that services all requests. The launcher will have to be privileged, but will reduce the capabilities required to the extent possible. The launcher will accept a message from the user session handling portion of systemd that contains the environment information assigned to the user when the session is started. The launcher will accept a similar tear-down message from the systemd user session manager as well. In the future the set of messages accepted by the launcher may be expanded to accommodate modification of the user environment. The systemd user session initialization and tear-down will be modified (extended?) to send the user environment information to the launcher. This is a saner approach than attempting to glean the information from another process. It provides a clean interface and assurance that the information is accurate. It allows for future extension. It works with the systemd model, rather than at odds with it. > -----Original Message----- > From: Jussi Laako [mailto:[email protected]] > Sent: Friday, October 11, 2013 2:04 AM > To: Schaufler, Casey > Cc: [email protected] > Subject: Re: [Dev] Tizen 3.0 proposal for fixing OSP/WRT/Core hard-coded UID > issue > > On 10.10.2013 19:15, Schaufler, Casey wrote: > > Only if you look, and you still don't know if the other side broke the > connection and is still running or if it died and there's a different process > running with the same pid. > > For example in gsignond we have p2p socket for D-Bus, so in case the other end > broke the connection, by doing so it also ceased to receive any services and > all > it's remote objects were destroyed. > > If it's a different process under same PID, then the socket descriptor cannot > be > valid anymore. > > > Except that the original process could have close()d the socket and still be > running, so the test in (3) yields a false negative. And, how do you do > validate > that "(1) is still intact"? > > If it did so, then we wouldn't perform any action for it either anymore. > It can get the request done at phase (1) completed only by being around at (3) > too, since it is anyway required in order to receive reply to the D-Bus > message. > > You get error if the socket's other end was terminated at least latest when > you > try to read() or write() to it. IMO, getsockopt(SO_PEERCRED) should also fail > if > the peer has closed the socket and terminated the process (I have not verified > this yet though, but it is easy to do). > > > The way I implemented ACL in gSSO for standard Linux desktop (just DAC > enabled, no MAC support) is that we have a p2p D-Bus over socket between > client application and gsignond (works also with session&system bus). > When request is received over the socket, SO_PEERCRED is used to fetch > callers PID and then /proc/PID/exe symlink is dereferenced to binary path of > the caller which is then compared against the ACL defined for stored > credential > and then response is performed and sent back over the same socket. So in case > the application terminated meanwhile and the process got replaced with > something else, the application wouldn't be able to receive the response it > wanted. Or at least it had voluntarily given up it's privileges to someone > else... > If someone has better ideas how to do it with D-Bus I'd be more than happy to > hear about it! > > > --- 8< --- (maybe OT) > In these cases databases are also protected from the user, gsignond is running > with setgid to "gsignond" group, but running with users' uid. > Then databases are stored in a directory that is only accessible to uid=root > gid=gsignond while per-user database is only accessible to uid=user > gid=gsignond. User is not member of "gsignond" group. This way user cannot > access the database directory, while gsignond cannot accidentally access > databases of other users even if it had a bug... _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
