Le 07/10/2014 13:30, Jussi Laako a écrit :
On 7.10.2014 13:47, Rafał Krypa wrote:
It seems that proposal for hook support in gumd failed, so we cannot
rely on this either.
Script hook support was added. Post-user-add scripts are in
/etc/gumd/useradd.d and pre-user-delete are in /etc/gumd/userdel.d.
There are also corresponding groupadd.d and groupdel.d directories.
Proposition from Rafal is far more resistant to potential failure as the
addition of user is done under the control of the security manager and
the risk unstable state resulting from a failure (such as power lost) is
lower.
I have an idea for doing it better that I'd like to discuss: provide
user management API in security-manager and let security-manager call
gumd. This is consistent with the general concept for
security-manager and would add just one more security mechanism for
it to handle. Then all Tizen logic for
user management could be implemented there, keeping gumd generic and
free of Tizen-specific hacks. Consistency of user configuration would
be easy to handle.
What do you think about it? Please share your comments.
I don't mind this, as long as we don't end up in long chains (deep
layering)... gumd interface is still of course there, so it is up to
integrator to decide how they want to do things.
I do agree that the chain should not be long and slow but I disagree on
the idea to leave a security related architecture choice to the platform
developer.
I we encapsulate user creation and removal in the security manager, we
shall restrict those call to the security manager.
Regards
Dominig ar Foll
Senior Software Architect
Open Source Technology Centre
Intel SSG
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
