Dear All,

We have lot of super users in business and security an issue at the moment.

I tried to change permission on otstpvtemul object to root so that no one could run shell from from run program.

Now the issue is some of the customised scripts are calling the mailx and other unix programs through the script and they are also stopped by the above change ownership.

Is there any way we can stop shell from super users other than user management.

Please help

Thanks in advance.

Eric.

Hi Eric,

you need to change the file permission than the file ownership.

also, check the permission of the object ottstpshell which gives the shell access. I think you were checking the object of terminal emulator (otstpvtemul).

I dont think that affects the email interface because, they are usually called with run.baan.prog() or shell() [I am not sure with the effect on shell] functions.

But I wonder if you are using the BaaN Standard emailing/outlooking interfaces with ttcmf.

Hi NPRao

We are using c3 and porting6.02,Bw6.03 and latest standard.
HP11 and Oracle8i.

Could you advice me how I can stop shelling out from run program for all super users other user management.

The program which call unix mailx is using shell().

My intention is to stop calling shell to the Unix.

thanks in advance

Eric.

Eric,

Based on your problem description I think you might try this possible solution -

1. change the file permission than the file ownership, on ttstpshell/otstpvtemul.

2. chmod of the $BSE/tools/ttstp/ostpshell to 700 or 744.

3. recode the email interface script replacing the shell()with run.baan.prog() function.

1 more question for you -

I think we can remove the shell access from the user data template and still use the shell() command in unix to get the mail functions working... I dont know if you tried that option.

Please let us know the results.

NPRao,

When I talked to the external developer who originally wrote this script told me the run.baan.program would evoke the ttstpvtemul.

Also we found difficulty with the user management as around 50 super users in business and it is quite difficult to take away the rights from them.

thanks,Eric.

Hi Eric,

I dont seem to understand your problem with the user management.

It is very easy to remove the shell access from the user data template and just do a runtime, logout and log back in for the changes.

Can you please explain it clearly.

Thanks!

They are super users, that mean that if you remove their shell access, they can put it back!...

If I turn everyone to normal users then the issue is previous superusers would cry on permission problems.

I am not sure whether certain functional session needs explicit permission in baanc3.

Also we face permission losing after regeneration Dem desktops.

Thanks in advance for any information.

Eric.

As default policy, a super user should only be a user that needs a lot of access to tools sessions (developpers and/or system administrators) - people that know what they are doing in Baan and usually, they need access to the shell.

All the rest should be normal users, and the authorizations should be given for only the sessions they need access to. We always estipulate during installation phase what kind of policies will be set up. Normal users mean harder work regarding authorizations but it compensates in a more safer environment.

A super user should also know that beeing so means beeing responsable (I know, not always), but for the ones that break the rule, the punition will be to be changed to a normal user and subsequent lost of authorizations :)

Hi Eric,

Victor is right. So you should come up with creating new templates with give some broad authorizations to those developers, like full authorization on the tt-adv modules, no authorization on the tt-iex, dba kind of stuff, VRC specific development authorization, time zone and shell access authorization, you can even have table field authorizations where you can specific the user data template to be a READ only field so that they cannot play around with timezones and shell access.

Security is a very important issue. If you have a lot of super users they can change any of the system settings. I have personally seen, where the templates were manipulated, deleted etc and as BaaN Administrators we are responsible for keeping the system safe and stable.

If the system is open for any one to change the parameters/settings then you can never catch the culprit if anything is tampered.

When I came up with Authorization Management System and template ideas, all the developers made noise of taking off the authorizations. Luckily, my boss supported my idea, and that I am open to discuss why they like to have authorizations on the sessions which are more baan administration related and not development related. My main point which won the discussion was - I am open to make everyone to be Super Users but if anything is messed up in the System the developers take the same blame and responsibility as me. I would not compromise on the system security to making some individual developers happy. If some developers needed additional access like job authorizations we created new templates and linked to them.

After 5 months now, things seem to be stable a lot and people got used to the template based authorizations. Sometimes, developers act like Demi-Gods :D so talk to them and make your way out...

Good Luck!!! :)

Hi Eric,

I found more information from the tools manual -

Syntax

long shell( string command(.), long mode )

Description

This starts the vt200 compatible terminal emulator to execute the command specified in the command argument. The shell (for example, UNIX, VMS, or MPE) process is connected with the bshell by means of a pseudo tty. Running a shell does not block the bshell. You can switch to another window and perform other tasks.

Arguments

command The command to be executed.
mode This can be a combination of the following options:
0 No main window is created for the terminal emulator. This may result in starting a terminal emulator in the main window of the process that calls the shell function. The first status field displays "ottstpvtemul" while the shell process is running.

I think you can try to remove the permissions of the object ottstpshell and keep the permissions on the object ottstpvtemul.

We are on the latest BaaN Release-5.2, I also found another object - ottstpivtemul.

Please post your findings here.

Thanks!

Eric,

About this one:They are super users, that mean that if you remove their shell access, they can put it back!... Go to the $BSE/lib/user and give users only read permissions on the file, no write permissions. Then they will not be able to convert their changed data to RDD.

Hi De Groetjes van OmeLuuk

Super Users are there for some reason like they need changing the PC and company. So they need to convert to runtime.

I think Unix (Security) group change may be the only solution left if Super users exist.

Thanks for your suggestion.

Eric Thomas

There they can use the
-- -set PACKAGE_COMB=OPER_002 -set BSE_COMPNR=102

Hi De Groetjes van OmeLuuk

Please give me the -- -set variables for USER.
If possible all -- -set variables.

I was searching for -- -set USER.

thanks in advance.
Eric Thomas

Eric,

A ton of the -- switches can be found in this thread: background info on bshell options (http://www.baanboard.com/baanboard/showthread.php?threadid=95&)

-- -set USER=alterego
In that case the user must be defined in the ttaad2100m000 session with its own characteristics (may even be normal user), package combination, company etc.

The only thing is: the alterego should use the same OS login as the original user.

Better in that case is:
- Change all users into normal users,
- add for each "real" super user a alternative user id
this user id is super user with predefined fixed settings (then do not allow convert to RDD). The super user use the OS login from the original (normal) user.
- if super user equivalence is needed they will need to use the -set USER= setting
- you can log what user ID's are used with the licd-logging for evaluation purposes.
- The super user setting can be stored in the bwc file.