Hi Dmitry,
I reviewed our previous discussion on setting up stunnel by envvars...

On WCE, if you really want to have a unic code to manage envvars...
well ok, you have to write a stub for ExpandEnvironmentStrings,
that either performs %XX% replacement from predefined values OR reads those values from a wce-specific "pseudo-env-txtfile".

As there is only ONE user in WCE, it is quite straightforward to write such stub, that will be universal for any wce terminal:
 the predefined values can be identical for any wce terminal.

NB : I already mentioned that (re)configuring stunnel through envars is not safe, at least on Win32 platforms: on those systems, env vars are stored in the registry (and synchronised with specific system calls): every malicious sw that can hack the registry can change env vars, it is of course very easy in we use "user" env vars, not system env vars.

Yours sincerelly,
Pierre

Le 10/09/2016 09:40, Dmitry Bakshaev a écrit :
we used patched version on many workstantions (linux and windows) and found that this feature allows to flexibly and automatically manage the stunnel configuration on the workstations.

environment variables like $HOME, %USERNAME% and others defined once and never changed, that does not affect stunnel restart and configuration reload.
but it allows us to have a single configuration for all users.

the only question that remains: how to use this feature where there is no environment variables (WinCE, which we do not have).
may by ExpandEnvironmentStringsA stub specifically for WinCE?
any comments, Pierre?

2016-07-07 15:42 GMT+04:00 Dmitry Bakshaev <[email protected] <mailto:[email protected]>>:



    2016-06-01 12:29 GMT+04:00 Pierre Delaage <[email protected]
    <mailto:[email protected]>>:

        Hello,
        To my mind, admin tasks such as conf file customization,
        should be performed by admin scripts, not app running in admin
        mode.

        With *GnuWin32 *sed AND echo commands, things are really simple :

        *stunnel.conf :**
        *

        cert = %USERPROFILE%\.config\my.pem (windows)

        output = %APPDATA%\stunnel.log (windows)


        *script "envsed.bat" on Windows :**
        *

        cat stunnel.conf | ^

        sed -r -e "s/^(.*)$/C\:\\Progra~2\\GnuWin32\\bin\\echo.EXE \1/e"

        every envvar "à la windows" is expanded .... Will work the
same in Linux.
    yes. this is primary goal of this patch - do not edit (manually or
    with sed) config file for each user.
    if user added/removed, if port/host changed, etc.
    admin mantains only one config that fit all users.

        If we really modify stunnel to do that job, I recommend to
        (try to) use stubs for WCE trying to keep one main code, and
        keeping an acceptable behavior in WCE, instead of playing with
#if WCE #else etc ...
    I am not familiar with the Windows CE, first and last time when
    seen the WinCE-device - the beginning of the 2000s. point into the
    right direction if you know.
    win32 has native ExpandEnvironmentStringsA() function,
    on other platform used stub/wrapper around getvar() function
    (#ifndef USE_WIN32).
    WinCE do not has ExpandEnvironmentStringsA() or getvar(), besause
    do not has environment variables.
    #ifndef _WIN32_WCE - simple way to not execute unnecessary code at
    all,
    but attached patch version has ExpandEnvironmentStringsA stub for
    WinCE, please review it.

        Another way to proceed is that stunnel recognizes a very small
        set of "pseudo-envvars", like eg we can find in samba conf
        files, such as, eg, %u for current user home folder, and that
        it expands (or "translate") internally with its own logic (of
        course using system calls if needed), but in any case, stunnel
        has to do some work for tokenization, something that I think
        dangerous : it would not be good that stunnel expands ANY
        envvar, known or UNKNOWN, without being able to predict the
effects on its execution.
    environment variables values owned by user. only owner or admin
    cat change it, not any-other user.
    starting process with admin/system/current_user privileges process
    inherits admin/system/current_user envvars values. stunnel not
    expands ANY or UNKNOWN envvars - only those that admin will
    specified in config file.

        Moreover, envars can be modified on the fly in an
        unpredictable way: what if stunnel reloads the conf after an
        envvar change ? if it even does NOT detect the change, there
        may be issues ...and if it detects the change and reloads,
there may be other issues...
    if running process not modify envvars by himself
    ExpandEnvironmentStrings/getvar expands to values taken on process
    start.

        Anyway, for the purpose of having multiple stunnel processes,
        running in user space, started from USER command line, it does
        not appear clear to me why an admin should create the USER
        conf files...the USER should be aware of what is he/she doing
with stunnel?
    admin manages stunnel and applications configuration on server and
    client side: hosts, ports, other stunnel options.
    user has own private certificate used with stunnel and works with
    applications through stunnel.

        and it is not clear why and HOW multiple users, logged-on on
        the ?same? machine, each working in USER SPACE, should run
stunnel simultaneously ...
    not necessary simultaneously - stunnel may use same ports on
    localhost for all users (from one global config).
    users alternately starts his own stunnel process with own
    certificate (path expanded from one global config).

        Question is also : if stunnel is running as a service, how
        will it deal with conf file containing ENVVARS, and what
        interest for this as system-wide stunnel just need one unique
        conf file.

    on server or client side? for example on server with miltiple
    stunnel instances for create predictable log files names (without
    manually editing): output = /var/log/stunnel/stunnel_${SVCNAME}.log

_______________________________________________
stunnel-users mailing list
[email protected]
https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users

Reply via email to