Hi Jussi,
On 05/03/2014 14:17, Jussi Laako wrote:
> 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...
>
Do you have a timeline for this ?
Depending on when the functionality will land, we'll have to add a
temporary stub (on useradd with hook scripts) or not.
>> ${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.
LGTM
>
> 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?
Yes, this is probably enough.
>> Questions
>> ---------
>>
>> 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.
>
Agree. Let's use simple hooks in post-create and pre-delete steps.
>> 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.
>
Yes, you're right. Let the scripts run synchronously and sequentially.
If a script takes time... hum... it's because this time is needed to
complete its task :-)
>> 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.
>
Yep, let's ignore retcodes.
Logging scripts outputs could be a good idea (syslog, dlog ?)
>> 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...
Right now, I'd prefer to run as root because the scripts we'll transpose
from spec files are actually run as root (in the mic chroot). You could
still call a su in a script to act as the user (except that we still
have smack concerns with su: the smack context switch is not done yet)
Another reason is that the hooks are probably there to setup/destroy
resources related to a user, but stored/handled at the system level
where the user himself doesn't have rights (global databases for example).
It's probably not the most secure situation, but actually I don't see
how to run differently.
Thanks for your explanations. We can go forward on multiuser migration
with this new mechanism coming soon in our toolbox :-)
Best regards,
Stéphane
--
Stéphane Desneux
Intel OTC - Vannes/FR
gpg:1CA35726/DFA9B0232EF80493AF2891FA24E3A2841CA35726
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
