This user is not part of the bsp group and needs access into the BaaN system. After I set him up in the system/environment etc, he is not able to login.

I found wierd messages in the $BSE/log -


log.bshell6.2:2002-08-21[02:23:10(UTC-01:00)]:E:axjacob: Errno 13 (Permission denied) bdb_errno 0
log.bshell6.2:2002-08-21[02:23:10(UTC-01:00)]:E:axjacob: Log_mesg:
log.bshell6.2:2002-08-21[02:23:10(UTC-01:00)]:E:axjacob: Error during sopen(${BSE}/lib/user/uaxjacob;${BSE_REM}!${BSE}/lib/user/uaxjacob, )

log.bshell6.2:2002-08-21[02:23:10(UTC-01:00)]:E:axjacob: Error during sopen(${BSE}/lib/datecurr;${BSE_REM}!${BSE}/lib/datecurr, )
log.bshell6.2:2002-08-21[20:35:27(UTC-01:00)]:E:axjacob: user_type S language 2
user_name axjacob tty locale ISO88591/NULL
log.bshell6.2:2002-08-21[20:35:27(UTC-01:00)]:E:axjacob: Log_mesg: Not authorized to run as user 'axjacob'
log.bshell_dev:2002-08-21[15:46:19(UTC+08:00)]:E:axjacob: user_type S langu
age 2 user_name axjacob tty ote locale ISO88591/NULL
log.bshell_dev:2002-08-21[15:46:19(UTC+08:00)]:E:axjacob: Errno 2 (No such
file or directory) bdb_errno 0


I wonder whats ${BSE_REM}! entries are ?

Any clues will be appreciated... :confused:

NPRao,

Your user needs to be in the group 'bsp' or else you will have to make a whole bunch of configuration files and directories world readable (e.g. $BSE/lib/*) which is not advisable.

$BSE_REM comes from a remote user setup.

Hi Pat,

Thanks for the tip... I was also thinking in the same line, maybe I needed to set up the remote user data but I ruled it out, as the user was on the same system and not logging in from another.

What are all the files which needed to be modified if I need to give this new user access to our BaaN system?

This also bring us up another issue, if we build new web interfaces to the BaaN system, do we have to set up all users as part of the bsp group? In that case, I would prefer to explore the previous options/configurations...

NPRao,

To find out which files are required, you could start the session with a dbslog trace but I would assume that alot of files/directories in $BSE/lib, $BSE/dict, $BSE/application would have to world readable. Basically each single file - whether configuration file, report file, script file etc - will be using.

I can't give any advice on the webinterfaces as I have never used those before.

NPRao,

On unix you can use the trick to use a set-group id bit on the bshell executable. In that way the user gets access to this group and the advantage of it is that he/she can't do modify things on unix level.

I have used this succesfully in some implementations.

Rgrds,
Han

patvdv
To find out which files are required, you could start the session with a ... -- -dbgfile -keeplog -logfile files_opened_ok
or
-- -dbgfdev -keeplog -logfile all_file_actions
trace but I would assume that alot of files/directories in $BSE/lib, $BSE/dict, $BSE/application would have to world readable. Basically each single file - whether configuration file, report file, script file etc - will be using.

I think you also not want the ${BSE_TMP} to be "world" writable...

Han, do you want to explain more on how to do this with the " set-group id bit"?

OmeLuuk,

Thanks for the tips... I will have to try to research more tomorrow.

I think we got most of our $BSE files/directories at 755 or 775 modes, except for few edi, log and other directories at 777 modes.

I guess Hans means to use -

chmod -R u+s files/dirs or
chmod -R g+s files/dirs

so that others can execute the files as "virtual" owners of the file.

I think to keep up more safety, we should add this command with option-

chmod -R u+t files/dirs so that the other users can still access the files with the super user bit (s) option and also that they cannot delete/remove any files due to the (t) option.

I would be think again before switching on sticky bits (s) on a bunch of files and directories. Besides the side effect of the text bit (t) by which it prevents removal except by the owner only works on directories, not files.