Hi Auke,
Kok, Auke-jan H wrote:
On Thu, Mar 6, 2014 at 7:49 AM, Stéphane Desneux
<[email protected]> wrote:
${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
personally I really hate the idea of more scripts... are we sure this
can't be done without scripts? I assume the answer is no, but I'd like
someone to confirm it.
I insist on the fact that the easy/fast path for multiuser migration is to move
some postinstall scripts from spec files to scripts called at user creation
time. This doesn't mean that there are no other ways to do the job.
Before thinking about running some scripts at user creation time, we already
made some lazy init of resources at first access. This is the preferred way to
do things but sometimes, it's not possible without changing a lot of things. A
simple script is easier to debug and maintain.
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.
I have some issues with this. Are we expecting tools in scripts to use
these values? It sounds horrible to me that a script could be told to
set some bits on disk to owner 123 even though user 123 does not exist
yet.
You won't know that the user has uid 123, but you'll know the username, homedir
etc. So, it's still a possible place to do something (but no chown !).
But we agree: IMO, it's useless to do anything before user creation (resp. after
user deletion), but I had to ask... I don't see what should be done before
creation that couldn't be done after.
you can sure have a pre-script run assuming that /home/newuser does
not exist yet, but I really think that uid 123 should be created
*before* the pre scripts run.
So these are post scripts :-)
I think we agree on this:
- gumd creates the user 123 THEN runs the (post-)create scripts
- gumd runs the (pre-)delete scripts then deletes the user 123
Questions
---------
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.
no, please no
If needed distinguish between FATAL and WARNING error codes, but
scripts *must* be able to tell the system that something critical
failed and the user could not be created.
Example: krb5/ldap user plugin checking AD credentials so that a user
may actually be part of a domain. If it fails, the system should be
able to halt user creation so a new user account can be prevented that
is not vetted by the administrator.
This sounds reasonable for this use case, even if I doubt that a single script
at post-creation time could deal with such mechanisms. In this case, there
should be multiple plugins/modules implied everywhere: gumd, pam, ...
Anyway, it's not a bad idea to have simple retcodes: at user creation time, if a
post script returns:
- 0: it's SUCCESS and we continue with next script
- 1: it's a WARNING and this should be notified somewhere. but we continue with
next script
- 255: if's a FATAL error, this should be notified, scripts exec stops and user
creation must be rolled back
The final retcode for scripts exec is made with all retcodes OR'ed.
At deletion time, it could be the same process: if a script returns a FATAL
error, the user deletion must be canceled. (do we have some cases where user
deletion should fail ?)
Logging scripts outputs could be a good idea (syslog, dlog ?)
please, no more dlog. User creation is AUTH type logging, so syslog()
seems the appropriate location. Also syslog is widely adopted and
supported, whereas dlog isn't.
Agree.
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.
many security concerns, DO NOT take security of components like this
lightlly, please.
Sorry if I wasn't clear enough. You can be sure I don't take this lightly: it's
really not my feeling.
The point is: do hooks must be run as root or as the user ?
My answer is: if we run the scripts as the user, it's useless as we won't have
enough privileges to initialize the needed resources outside user scope. So we
have to run them as root (or as a privileged user) and this implies some
security holes we have to address.
That's why I said "it's probably not the most secure situation" and I'm not
satisfied with that, but I don't see any alternative actually.
If you take user-provided input, and pass it to scripts... (exercise
left to the reader to finish this sentence).
I don't see the point. AFAICS, a script will get more or less the following
arguments, provided by gumd:
<username> <userid> <homegroup> <homedir>
so there's no user-provided inputs, except the username which is not a threat if
it was checked correctly by gumd (/^[a-zA-Z0-9]{3,15}$/ or equivalent)
Am I wrong or did you have something else in mind ?
Thanks for your ideas.
BR,
Stéphane
--
Stéphane Desneux
Intel OTC - Vannes/FR
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
