Hello Imran,
As for the security-manager status:
- we're wrapping up on the security-manager offline mode - a CLI tool
has been created and patches are being merged gradually into tizen.org
gerrit repository
- we've started implementing the API for handling user management inside
security-manager
- we have a dependency on several features from cynara - discussions on
the schedule are going on right now
We also have a small dependency on GUMD: what about additional data
passed to user scripts. I mean for example: user type.
I'll come up with a schedule as soon as we agree on the dependencies
with cynara guys.
On 25.11.2014 14:28, Zaman, Imran wrote:
Hi Rafal!
Can you please share the details as to where are we with gumd and security
manager? Any idea about the timeline would be great.
BR
imran
________________________________________
From: Dev [dev-boun...@lists.tizen.org] on behalf of Rafał Krypa
[r.kr...@samsung.com]
Sent: 27 October 2014 14:31
To: Jussi Laako; Le Foll, Dominique
Cc: dev@lists.tizen.org
Subject: Re: [Dev] Gumd and security-manager integration
On 2014-10-16 14:39, Jussi Laako wrote:
On 16.10.2014 11:43, Rafał Krypa wrote:
Could you please describe this subject in detail? What problems did you
encounter while considering integration by hooks? Why was it considered
unfeasible?
If similar problems could also affect integration with security-manager, I'd
like to avoid them as early as possible.
Conclusion was that it is impossible to perfectly roll-back hook actions in
case of failure because the roll-back can also fail. If not for anything else
but due to bugs in implementation.
IMHO a perfect roll-back for operations like user creation and removal isn't
that important.
If some step during creation of a user fails (or is interrupted by power loss)
it should be enough to leave the user in half-created state. Such half-created
account should have the following characteristics:
- cannot be utilized, prevent users from logging into it (this can be achieved
by enabling the account in the very last step of the process)
- can be enumerated and removed, like any proper user account
- until removed, cannot be re-used by subsequent user creations
Having that, a device administrator could recover from failed user creation by
entering user management again, removing the half-baked account and trying to
create it again. It is possible to handle user removal in a similar way.
To be honest, in my proposal for wrapping gumd with security-manager functions
I didn't intend to provide fully transactional removal and creation of users. I
considered it too difficult and not worth it. And similarly, as far as i know
there is no roll-back support for failed application installation (or
de-installation or upgrade). Do we need to discuss it for applications as well?
Dominig, if you have any concerns about my approach, please let us know. At the
moment I don't see technical reasons for choosing gumd wrapping over hooks.
Since hooks seem to be preferred by gumd developers and should be easier for
all of us, they look like a viable option to me.
Best regards,
Rafal Krypa
---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
_______________________________________________
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev
--
Samsung Enterprise Portal mySingle
Samsung_Logo_for_Mail_Signature
Krzysztof Sasiak
Samsung R&D Institute Poland
Samsung Electronics
k.sas...@samsung.com
_______________________________________________
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev
