Hello jep,
please see below my experiences during the past years:
Hello,
I've tried
Security/2 (0.4.5) with
eComStation 2.0 GA and found it to be very interesting and with potential.
It seem to allow us to add secured login to the desktop and possibly multiple WPS desktops (1 per user).
There are however some things that remain unclear to me, that I need to ask you for guidance.
As mentioned by others in the original topic from 2007, I also have problems to set the HOME environment variable (system doesn't use it), it use the OS2 folder by default and it seem to me that one need to copy/create e.g. os2.ini and os2ini.ini to the folder one set as the user directory?!
The HOME variable is pre-set with the new user (and password) being created and has to be changed manually to something reasonable. All this you can find stored in file ?:\ecs\SYSTEM\SESS\etc\passwd.
My example look like this:
root:$1$K2hF$IbJXjkDPrAesJnz3rYA5s/:0:0::$C\HOME\ROOT:$C\OS2\CMD.EXE:$C\OS2\CMD.EXE:
test:$1$K2hF$igrk4vs2yp38nMD8Gh0MK1:100:0::$C\OS2:$C\OS2\CMD.EXE:$C\OS2\CMD.EXE:
So for the first user - root - HOME directory is set (and working!) to C:\HOME\ROOT, and for the user test is is pre-set to C:\OS2.
For os2.ini and os2sys.ini: yes, you have to create a new set of these files in the HOME directory for each of the users (or copy the current versions from ?:\OS2). This is actually a good thing, since this allows for each user to have his/her "personalized" settings stored into his/her personal HOME directory for each of the desktops.
Note: Although I tried
really hard, I was never able to fully duplicate the existing desktop to more functional copies!

Hints on this are welcome!!
Hint: to set additional environment variables for the current user create a file called "environment" in the HOME dir for the current user. My example of C:\HOME\BOLDOS\environment file contents:
DESKTOP=C:\Desktop
USER_INI=C:\HOME\BOLDOS\OS2.INI
SYSTEM_INI=C:\HOME\BOLDOS\OS2SYS.INI
MOZILLA_HOME=C:\HOME\BOLDOS
By this, user BOLDOS has i.e. separately stored profile info and files for Firefox browser.
Another ting, am I supposed to edit the acls-file by hand to allow/deny access various tools and folders?
Is there an editor (GUI, preferaply WPS integrated and then I mean not just a plain text editor) somewhere that can simplify the configuration task?
There is no such thing as dedicated ACLS editor nor there is any GUI application to do that. Moreover (since SESS is only a layer or drivers and a bunch of some basic cmd line utilities), there is no integration of SESS into desktop to speak of. Unfortunately SESS does not seem to be a fully finished product. This means until a) GUI utilities are created and more importantly b) it gets integrated into desktop by Mensys in some future version of eCS, we are stuck with the bunch of utilities we have and manual editing of cfg files

There are also some other minor issues, such as this one:
I was thinking to lessen the rights to vital parts of the system, so that user has only i.e. read and execute rights to vital system directories such as C:\OS2, C:\ecs, C:\MPTN etc. Unfortunately, the desktop seems to require write access to C:\OS2\os2.ini and/or C:\OS2\os2sys.ini (do not now remember to which one), even if you have separate copies stored in HOME dir for the current user. As a result, you are given a warning message by desktop every 1 minute that desktop cannot write access the file C:\OS2\os*.ini. Most probably this can be overcome, unfortunately for me I have not found a way.
I'd like to set one account to allow me to start the DOS Command line, but that is not possible as it denies it. What setting should I use? An editor or documentation by example would be nice to have.
//Jan-Erik
Yes, it seems to be possible to run DOS command line only when logger in as root. I believe this is due to the limitations of SESS subsystem, since it is not able to process the correct APIs, thus if you are logged as any other user than root, SESS will not "allow" to run DOS. If you are logged as root, then I believe you have full system access by default, thus the limitation of SESS not being able to control the correct APIs does not apply and the system will run the DOS cmd line just fine.
For the documentation:
it actually exists, in C:\ecs\SYSTEM\SESS\doc. there is a good explanation + some examples. The rest is trial and error

Please let me know your thoughts and further experiences, I would be quite interested to know your progress

Stefan