Le 14/10/2013 11:22, Jussi Laako a écrit :
On 12.10.2013 1:16, Stéphane Desneux wrote:
If we don't want to set a static address for the dbus session address
(would it be a security hole ?), it may even be more tricky: the DBUS
session address will be set when libdbus forks dbus--session, i.e. when
the first dbus app will start. From a security POV, I prefer random
sockets but it's even harder to define what's the correct environment to
paste into the application process.
No, dbus session bus daemon should be started explicitly at session
creation (like on desktops) and it will generate a random address
which then gets set to the environment.
Now the environment seen by the dbus-daemon and any services launched
by it is fresh clean from the session creation and not something from
any app's environment.
If launcher is auto-started by session dbus-daemon it will
automagically inherit clean user environment and that will get
properly passed on to any launched applications.
Although for launcher you could rather use p2p dbus and not session
bus since you want to keep the launcher running always anyway and this
way you get more control over the environment. Address can be still
random and passed on as part of the session.
I am afraid that it's said in Britain, "you cannot have the cake and eat
it".
We will need to select one mode of operation and work around its
inherent weaknesses.
1) Single AMD daemon
-------------------------------
PRO : Interesting for saving resources and enabling a tight control of
which application is launched and how they are launched.
CON : any ENV variable which is set by the user desktop or home shell
need to transfered from the user session.
2) AMD daemon in user land
---------------------------------------
PRO : Easy access to the environment
CON: Little control if what/how Apps are launched
My proposition would be to create a lib which is an AMD client which
would be used to pass ENV info about a given UID to AMD.
The model would not allow to rewrite a variable without a full user
reconnection (exception could be granted later if required).
a) Static model
--------------------
In Tizen vertical which uses a static startup model like it is the case
in IVI and Mobile today. We could add that lib in a platform software
which is used in the launching phase (e.g. systemd or pam).
Set a boolean in AMD limiting ENV creation to 1 single message.
b) Semi dynamic model
--------------------------------
In the case where a few core component are launched by the home shell
(d-bus is a prime candidate) we could add that lib to the concerned few
daemon (e.g.d-bus, wayland, ...)
Set a list in AMD limiting ENV creation to a set of binary (a Smack
label could do well)
c) Fully dynamic model
-------------------------------
In the model where the home shell is fully controlling the session
launch (e.g. Gnome, Enlightment, ...) we could use the same lib to
create a utility which can be called by the home shell.
Thoughts?
Dominig
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
