Hi Krzysztof! For the sake of clarity, gumd will be used by security manager for the two things below as well.. right?
- offline mode for security-manager - hooks handling for adding and removing users I will try to add such functionality soon to gumd; will update you soon.. BR imran ________________________________________ From: Krzysztof Sasiak [[email protected]] Sent: 09 December 2014 11:11 To: Zaman, Imran; [email protected] Subject: Re: [Dev] Gumd and security-manager integration Hi Imran, That's OK, we don't mind that at all, as far as gumd is the component responsible for the differentiation of user types. As for the timeline, we directly don't need to be able to get list of users. However, we see many usecases (for example users privileges administration), where such feature will be necessary in gumd. It would be great, if You had something ready in 1st half of January. As far as the schedule is concerned, I believe that by the end of this year we will push to security-manager patches implementing: - offline mode for security-manager - hooks handling for adding and removing users - usertype security profiles - initial implementation of per user privileges administration By Jan, wk3 we should be able to provide full user privileges administration and that's when we could use the getting list of users feature in gumd. As the holiday season is coming, and many people are taking some time off, this schedule might be a little bit inaccurate. On 08.12.2014 13:51, Zaman, Imran wrote: > Hi Krzysztof! > > Yes gumd can return the uid, name and usertype but user-type will be > evaluated based on UID ranges inside gumd itself (your component does not > need to depend on UID ranges). We can have four different UID ranges, system, > normal, guest and admin to differentiate the user types inside gumd. > > Btw Rafal already knows about it when we discussed that gumd does not have > its own db. There is no place in /etc/passwd where we can store the user > type. So relying on UID ranges inside gumd is the only way to go as per > current implementation. > > We agreed with rafal that separate gumd's db is not needed IIRC as it is not > trivial change and may require some serious changes and effort. > > It would be good to know timeline and commitments from your team regarding > the features that need gumd so that we know which feature is needed when, and > how shall we allocate our resources. > So as I asked once, please share your plan for features and timeline, then we > can work out the gaps properly. There is no point in doing something which > does not end up being used anywhere. > I can work out on the API once I have some time for it and once I hear some > plan from you. > > BR > imran > > > ________________________________________ > From: Krzysztof Sasiak [[email protected]] > Sent: 08 December 2014 14:33 > To: Zaman, Imran; [email protected] > Cc: Dominig ar Foll > Subject: Re: [Dev] Gumd and security-manager integration > > Hi Imran, > > About the API for listing users: I think we need to have it inside > gumd, as You've proposed. We wouldn't like to depend on uid ranges in > differentiating user types - this should be the job of gumd. As for the > data we would need: > * uid, name, user type > * it might be good to add some more detailed user metadata fetching in > the future > > You've only mentioned system and normal users. What about admin and > guest usertypes? > > On 04.12.2014 15:28, Zaman, Imran wrote: >> Dominig, >> >> gumd does not have any wiki page as of yet, but gumd has documentation (doc >> package) which is mostly up-to-date. >> Btw this functionality is still under discussion.. >> >> Will write a wiki page once I have sometime :-) >> >> BR >> imran >> ________________________________________ >> From: Dev [[email protected]] on behalf of Dominig ar Foll >> [[email protected]] >> Sent: 04 December 2014 16:10 >> To: [email protected] >> Subject: Re: [Dev] Gumd and security-manager integration >> >> 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 >> --------------------------------------------------------------------- >> 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 >> > > -- > 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. > > -- 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
