[Dev] [Multiuser] gumd further work

Jussi Laako jussi.laako at linux.intel.com
Wed Mar 5 13:17:56 GMT 2014


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

More information about the Dev mailing list