On 2014-11-26 11:38, Zaman, Imran wrote:
> Hi Krzysztof!
>
> Currently gumd does not support any additional data to be passed on to
> scripts, but we can look into it when you guys specify exactly which info.
> needs to be passed on?
> For user type, its not currently stored anywhere inside gumd (as gumd does
> not have separate db)
Hi Imran,
Why would it need a data base to pass such information? When a user is created,
it's type is one of the arguments passed by the client to gumd. Gumd knows the
value of this parameter and could pass it down to hooks.
> but from the UID_MIN and UID_MAX one can determine if its a system user or a
> normal user?
That would be very hackish. UID_MIN and UID_MAX are configuration variables
internal to gumd. These variables could change and hooks should rely on their
value nor shouldn't have to read and parse gumd configuration files.
We need gumd to pass user type to useradd hooks. If you need it to re-calculate
the user type using UID_MIN and UID_MAX internally in gumd, that's fine. But
the hook should get a simple value from {system, admin, guest, normal}.
Best regards,
Rafal Krypa
> _______________________________________
> From: Krzysztof Sasiak [k.sas...@samsung.com]
> Sent: 26 November 2014 10:11
> To: Zaman, Imran; Rafał Krypa; Jussi Laako; Le Foll, Dominique
> Cc: dev@lists.tizen.org
> Subject: Re: [Dev] Gumd and security-manager integration
>
> 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
> ---------------------------------------------------------------------
> 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.
>
--
Rafał Krypa
Samsung R&D institute Poland
Samsung Electronics
Office +48223778135
r.kr...@samsung.com
_______________________________________________
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev
