Hi Jussi and devs,
I've some suggestions to share on gumd to help in migration to multiuser mode.
Fpr background info on multiuser mode, please refer to the Tizen wiki where we
put documentation and guidelines: https://wiki.tizen.org/wiki/Category:MultiUser
Actually, we're in the first phase of the migration, that is: removing hardcoded
paths and uids from source code. This phase is ~60% complete right now but some
packages don't want to migrate so easily :-)
It's hard to be exhaustive on the difficulties we're facing and I'll take a
typical example to check what could be done on gumd side to make things easier.
The problem
-----------
In single user mode, the place where user data are stored is usually /opt/usr/.
So, in Tizen 2.2, when some user databases or other resources must be
initialized, it's quite easy to do it in some RPM postinstall script (coded in
spec file)
In multiuser mode, as each user should have his/her own resource, it's
impossible to try to initialize anything in RPM postinstall (and it's a
non-sense in most cases: users don't even exist at the time of RPM install in
MIC). And what about upgrades...
To solve this problem in some cases, we used the "lazy init" approach: We
created an init script (moved the code from spec file to a packaged script) to
be called inside source code at runtime: for example, to create a user database,
we can check if the database file exists just before opening it: if it's not
there, we can run the init script and recheck. The resource would be initialized
and populated at the first attempt to open it.
This trick is valid as long as the resource is "private" to a given package (the
resource is used directly and exclusively by one package and is opened in very
few source files).
Murphy's law: only a few packages are in the above case :-)
In other cases where a resource is shared by multiple packages, we'll have to
find another way to initialize it.
Why gumd could help ?
---------------------
When it's getting difficult to use the above trick, an alternative would be to
initialize the resource at user creation time.
After all, it's not far from what's done actually in spec files, except that the
initialization script shouldn't be run at RPM install time, but at user creation
time (later, at runtime, on the device itself, not in MIC)
That's where I thought about gumd (or more generally on a mechanism related to
user creation/deletion).
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?)
The hook scripts would be installed by the various packages which have to
delegate initialization of user resources to gumd. To sort things and make a
difference between pre-creation and post-creation scripts, we could have the
following names for scripts:
${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
That's how things are done in many distros (example on Debian:
/etc/X11/Xsession.d/ for X session init)
SO when gumd is about to create a new user, just before calling useradd, it
could execute all pre-scripts sequentially (/etc/gumd/useradd.d/*.pre). If
useradd was successful, it could exec /etc/gumd/useradd.d/*.post. Same applies
for deletion in the opposite way. When creation fails, userdel.d scripts could
be called to clear things (as if the user was deleted).
Questions
---------
Is gumd the right location to do those things ?
If no, which alternatives (in pwdutils for example) ?
If yes, pro/cons to do that in gumd.
Do we need to distinguish pre and post scripts ? post-creation and pre-deletion
may be sufficient ?
Scripts should be executed sequentially (synchronously) because some init
scripts could depend on others. What about "long" scripts ? Execute with a kill
timeout ?
What happens if a script fails ? (solution 1: ignore. solution 2: abort user
creation)
Security concerns ?
...
--------
This explanation was perhaps a little bit long, but this way I hope that
everyone has now the right vision of the problems we have to solve.
Thanks for listening and for upcoming feedback.
--
Stéphane Desneux
Intel OTC - Vannes/FR
Jussi Laako wrote:
Hi Stanislaw,
On 4.3.2014 14:05, Stanislaw Wadas wrote:
I would like to ask you what are the further plans in gumd development,
I saw that last commits are 2 months old.
We are now merging rest of the devel branch changes to master. We somewhat
recently made a new release on Tizen. But overall it is complete.
Can you tell if you are planning to remove
pwdutils and replace it with gumd ? What are your plans for gumd on IVI ?
I don't think we'd remove pwdutils, those utilities are used by spec files and
such. So gumd it not so much replacement for those command line utilities, but
more basis for creating GUIs for configuring users on the system. gumd is also
used by tlm to create and cleanup guest user home directories on login/logout
and such.
So if you need to create system users from spec files or scripts, pwdutils is
good choice. If you need to create or modify normal user accounts or groups from
C/C++ code (or anything that can call dbus), gumd is better choice.
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
