Hi,
On 5.3.2014 2:57, Stéphane Desneux wrote:
The basic idea would be to have 2+ hooks directories where some scripts
installed by packages could be executed at different times by gumd:
- /etc/gumd/useradd.d : hooks to be called when a new user is created
- /etc/gumd/userdel.d : hooks to be called when a user is deleted (to
remove some resources not stored in user homedir)
- ... other hooks (needed?)
This is good idea and we've discussed about it already before. We will
add this functionality...
${prio}_${name}.${when}
where:
- $prio ranges from 00 to 99,
- $name would be anything relevant: [a-zA-Z0-9_-]+ . source package name
is a good name !
- $when is "pre" or "post"
Examples:
/etc/gumd/useradd.d/10_bigbang.pre
/etc/gumd/userdel.d/99_armageddon.post
OK, we'll do this too. However, I'm thinking that we'll do it in a way
that doesn't mandate this format. So you can omit priority and/or the
pre/post suffix. In this case scripts are run in alphabetical order,
post-add or pre-remove. Makes things simpler for most normal cases.
We'll do the matching equivalent for groups too.
However I'm not sure about usefulness of pre-add and post-remove
scripts, because the user doesn't exist yet so things like file
permissions cannot be set.
For the arguments, we've been thinking <username> <userid> <homegroup>
<homedir>, is this sufficient?
Questions
---------
Is gumd the right location to do those things ?
Yes... :)
Do we need to distinguish pre and post scripts ? post-creation and
pre-deletion may be sufficient ?
I believe post-create and pre-delete would be sufficient. Pre-create and
post-delete are a bit dangerous, but we can support this if there are
valid use cases.
Scripts should be executed sequentially (synchronously) because some
init scripts could depend on others. What about "long" scripts ? Execute
with a kill timeout ?
Problem with timeouts is that timeouts are hard to define and usually
things start to take longer time as the system ages. For example
pre-delete script could take a long time if it needs to delete 100k
photos consuming 100 gigabytes of space. Killing a script in the middle
could leave a system in some really strange state.
What happens if a script fails ? (solution 1: ignore. solution 2: abort
user creation)
Maybe that should be reported back to the GUI/app as result to the dbus
call. We are now discussing how to do it. Without changing the dbus API
we could send script status signals for request id. Doing it even more
proper, we could return an operation object and signal status updates
and completion on the operation object.
Practically it needs to be just ignored, but at least from developer
point of view it would be good to know and in case something failed such
as out of disk space for ordinary user, it would be good to know that
user may not be completely successfully setup. In the end, the decision
is up to the app/GUI making a user add/remove call.
Security concerns ?
Not really, since the scripts are located in controlled place.
One interesting aspect is running the scripts as root vs running the
script as the user...
Best regards,
- Jussi
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
