On 10.10.2014 16:03, Rafał Krypa wrote:
* hooks mechanism needs to be enhanced: do post- and pre- hooks,
check error codes from scripts
Pre-user-creation and post-user-delete are kind of pointless, because in
pre-creation-state you don't yet have UID or anything else for the user,
just username. And in post-user-delete these don't exist anymore.
We can check error codes, but what would we do when there's an error? If
we would have filesystem that supports snapshots, we could roll back safely.
1. Access control
* Check whether the user is privileged to perform configuration on
other users
We can make group-based access control on this, I'd propose using
standard "wheel" group for the purpose.
* We've got Cynara for such checks, integration scenarios #1 and
#2 require gumd to integrate with Cynara
Is it already available and working?
2. Smack setup
* When a user is created, files in the new home directory needs
proper Smack labels
This is already done by gumd. It wouldn't have been possible to
integrate and verify gumd on Tizen without it.
But you should figure out how to do this correctly with respect to
/etc/skel as it works already for normal unix DAC permission mask...
* When a user is removed, it may require removal of Smack rules
for applications installed by that user
3. Cynara setup
* When a user is removed, we must remove all private Cynara rules
for that user
These are suitable for a pre-remove script.
* We already implement an offline, deamon-less version of
security-manager to be called by root during image creation. Is
gumd going to provide such tool as well?
We added support for running the daemon in p2p dbus mode through
environment variable, so you don't need to have dbus-daemon running.
This should be enough...
Taking all of the above into account, I suggest doing the integration
scenario #3 - wrap gumd in security-manager. This enables best handling
of Cynara and Smack configuration, keeps related logic inside (i.e. what
Smack label is assigned to home directory). It also doesn't require and
Tizen-specific changes to gumd, keeping them in security-manager, which
is a Tizen-only thing by design.
I think best is to use post-creation script for this purpose. But I can
live with this approach too as long as it doesn't require Tizen specific
changes to gumd...
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
