On 6.3.2014 21:30, Kok, Auke-jan H wrote:
For the arguments, we've been thinking <username> <userid> <homegroup>
<homedir>, is this sufficient?
These parameters are the ones passed to script called by "useradd". So
using the same set would also make possible to use same scripts for both
gumd and useradd.
I have some issues with this. Are we expecting tools in scripts to use
these values? It sounds horrible to me that a script could be told to
set some bits on disk to owner 123 even though user 123 does not exist
yet.
you can sure have a pre-script run assuming that /home/newuser does
not exist yet, but I really think that uid 123 should be created
*before* the pre scripts run.
IF we would support pre-create and post-delete scripts, UID naturally
couldn't be provided since the user doesn't exist yet. This is the
reason why I proposed to stick to post-create and pre-delete.
If needed distinguish between FATAL and WARNING error codes, but
scripts *must* be able to tell the system that something critical
failed and the user could not be created.
Problem is with rolling-back from a fatal error case, because some
scripts have already completed while some others have not, and
subsequently running delete for the partially completed user creation
would likely also result in errors because the creation wasn't
completed. And this results in a case where the result is unknown state.
So my proposal is to just report results of each script to the
application making the user creation dbus call and let it decide how it
wants to handle the situation. It can call delete user right after if
there was an error, or it could just report to the user that user
creation wasn't completed due to errors (for example out of disk space).
Practically there are so wide range of devices and products using this
component that we cannot put suitable logic inside. GUI is most likely
product category specific so it can better handle the case.
Example: krb5/ldap user plugin checking AD credentials so that a user
may actually be part of a domain.
Your car probably doesn't have krb5/ldap (hopefully), so the errors need
to be handled different way than on enterprise-category tablet device...
- Jussi
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
