It already exists mechanism (scripts) that are run by useradd and
userdel. These scripts are:
/usr/sbin/useradd.local
/usr/sbin/userdel-pre.local
/usr/sbin/userdel-post.local
hooking it is really easy.
Best regards
José
On mer, 2014-03-05 at 15:17 +0200, Jussi Laako wrote:
> 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
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
