On 03/12/2014 02:22 AM, Stéphane Desneux wrote:
Hi all,
I agree: if things can be done without hooked scripts at user creation
time, it's clearly better. This also means more commitment on the
multiuser topic from developers and maintainers, which is also a good thing.
Now, having this consensus raises another question: if I suppose that we
support user deletion (please confirm that assertion !), what happens at
user deletion time ?
NB: for actual resources not in user homedir, the tizen-platform-config
package will help to move easily some files from /opt to /home simply by
changing the global tizen-platform.conf file (this is anticipated).
there should be no resources outside a homedir. simple. if there is a
default system config - it is owned by the system. it stays because any
newly created user will copy/start with that config (and if
needed/desired write a copy of that to $HOME/somewhere). if there are
user resources outside the users homedir (other than temporary things
like /tmp or /var/run that can get nuked at a reboot etc.)... it's just
plain wrong™. :) it's the app's job to deal with loading a system config
if no user config is done, to deal with writing out user config,
handling config upgrades etc.
I see at least two cases:
-1- a user-specific resource is stored INSIDE the user home dir
(database, files ...)
-2- a user has objects or is referenced OUTSIDE his/her homedir (global
database, global files ...) for example the media-server or package manager.
as above. #2 is just wrong (tm) if this data is user-related. rpm db is
not user-related data. it's system related and managed by the system.
user can read it, but not modify it (unless root - and if root then root
is modifying the system). this would be the case for any other system
data. same story.
If removing the user also removes his/her homedir, there's no problem
for case 1: all user related object will be removed correctly.
If we exclude deletion hooks on gumd, how can we deal with case 2 ? I
mean: what is the link between gumd and the daemons responsible for
those global, user-related resources ?
A solution can be to run the cleanup procedure at system start time (or
daemon start).
Pro: this would delete the resources associated to deleted/non existing
users later at next reboot
Cons: next reboot maybe longer
assuming a reboot to clean up imho is a bad move, but as above... case 2
just shouldn't happen (IMHO).
Other ideas ?
Thanks for feedback.
--
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
