Imran,
as well as to give the details by email, it would be nice if you could indicate which Wiki page gives that level of details. Regards Dominig Le 04/12/2014 14:56, Zaman, Imran a écrit : > Hi Krzysztof! > > We can add dbus APIs to gumd (and also offline APIs to gum-utils) where one > can have: > - list all users (system and normal) > - list normal users only > - list system users only > But the best what can be done is that it will be based on the (sys) uids > range defined in gumd.conf; and that is how e.g. IIRC ubuntu filters normal > users from /etc/passwd file based on uid range. > > Would it serve the purpose for you or you have some other requirements? > Moreover what information you would like to get for the user when you get the > list? (uid, name would be enough or ?) > > BR > imran > ________________________________________ > From: Krzysztof Sasiak [[email protected]] > Sent: 04 December 2014 10:27 > To: Zaman, Imran; Rafał Krypa; Jussi Laako; Le Foll, Dominique > Cc: [email protected] > Subject: Re: [Dev] Gumd and security-manager integration > > Hello Imran, > > One more question I keep forgetting to ask: does gumd have any API > for listing available users or there is some other way to do that. > > On 27.11.2014 15:51, Zaman, Imran wrote: >> Hi Rafal/Krzysztof! >> >> Okey gumd has been updated just now with the following change: >> >> scripts: useradd/userdel data: name, uid, gid, homedir, usertype >> (NULL for userdel script) >> scripts: groupadd/groupdel data: name, gid, getuid (calling process >> uid) >> >> So you can now proceed with using gumd. >> >> BR >> imran >> ________________________________________ >> From: Dev [[email protected]] on behalf of Zaman, Imran >> [[email protected]] >> Sent: 27 November 2014 13:53 >> To: [email protected]; Rafał Krypa; Jussi Laako; Le Foll, Dominique >> Cc: [email protected] >> Subject: Re: [Dev] Gumd and security-manager integration >> >> Hi >> >> Okey i will let u know when I have the time to do the change. >> Currently useradd/userdel scripts are passed on the data in the order (to >> keep it compatible with other implementation of adding user): >> scripts: useradd/userdel data: name, uid, gid, homedir >> scripts: groupadd/groupdel data: name, gid >> >> I will change the above as: >> scripts: useradd/userdel data: name, uid, gid, homedir, usertype >> (NULL for userdel script) >> scripts: groupadd/groupdel data: name, gid, getuid (calling process >> uid) >> >> Shouldn't be big change; will be added soon. >> >> BR >> imran >> >> >> ________________________________________ >> From: Krzysztof Sasiak [[email protected]] >> Sent: 27 November 2014 10:50 >> To: Zaman, Imran; Rafał Krypa; Jussi Laako; Le Foll, Dominique >> Cc: [email protected] >> Subject: Re: [Dev] Gumd and security-manager integration >> >> Hi Imran, >> >> About the additional data passed to the hooks: for now we need only >> user type passed to user added script. >> >> On 26.11.2014 12:22, Zaman, Imran wrote: >>> Hi Rafal! >>> >>> Thats why I asked. If u need usertype to be passed onto ONLY to useradd >>> script, then no db is needed. >>> Do you have any other requirements for passing data to scripts, please >>> indicate? >>> >>> If usertype is needed for any other script, then we need to consider gumd >>> specific db (I agree that UID_MIN, UID_MAX is hackish but thats the >>> quickest! as we will need sometime to implement gumd specific db if needed >>> for your requirements) >>> >>> So please list your requirements for passing "what DATA to what SCRIPT", >>> and then I can come back to you about the solution and timeline. >>> >>> BR >>> imran >>> ________________________________ >>> From: Rafał Krypa [[email protected]] >>> Sent: 26 November 2014 12:57 >>> To: Zaman, Imran; Krzysztof Sasiak; Jussi Laako; Le Foll, Dominique >>> Cc: [email protected] >>> Subject: Re: [Dev] Gumd and security-manager integration >>> >>> 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 [[email protected]<mailto:[email protected]>] >>> Sent: 26 November 2014 10:11 >>> To: Zaman, Imran; Rafał Krypa; Jussi Laako; Le Foll, Dominique >>> Cc: [email protected]<mailto:[email protected]> >>> 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 [[email protected]<mailto:[email protected]>] >>> on behalf of Rafał Krypa [[email protected]<mailto:[email protected]>] >>> Sent: 27 October 2014 14:31 >>> To: Jussi Laako; Le Foll, Dominique >>> Cc: [email protected]<mailto:[email protected]> >>> 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 >>> [email protected]<mailto:[email protected]> >>> https://lists.tizen.org/listinfo/dev >>> >>> >>> >>> -- >>> Samsung Enterprise Portal mySingle >>> >>> Samsung_Logo_for_Mail_Signature >>> >>> Krzysztof Sasiak >>> >>> Samsung R&D Institute Poland >>> >>> Samsung Electronics >>> >>> [email protected]<mailto:[email protected]> >>> --------------------------------------------------------------------- >>> 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. >>> >>> >>> >>> >>> -- >>> [cid:[email protected]] >>> >>> Rafał Krypa >>> Samsung R&D institute Poland >>> Samsung Electronics >>> Office +48223778135 >>> [email protected]<mailto:[email protected]> >>> --------------------------------------------------------------------- >>> 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. >>> >> -- >> Samsung Enterprise Portal mySingle >> >> Samsung_Logo_for_Mail_Signature >> >> Krzysztof Sasiak >> >> Samsung R&D Institute Poland >> >> Samsung Electronics >> >> [email protected] >> --------------------------------------------------------------------- >> 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 >> [email protected] >> https://lists.tizen.org/listinfo/dev >> --------------------------------------------------------------------- >> 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. >> >> > > -- > Samsung Enterprise Portal mySingle > > Samsung_Logo_for_Mail_Signature > > Krzysztof Sasiak > > Samsung R&D Institute Poland > > Samsung Electronics > > [email protected] > --------------------------------------------------------------------- > 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 > [email protected] > https://lists.tizen.org/listinfo/dev -- Dominig ar Foll Senior Software Architect Intel Open Source Technology Centre _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
