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.
