SAM restricted shell - strange behaviour...

[André Sorge]

Hi there,

got a strange problem using sam on an HP-box using 11.i...
I restricted sam gui for users using sam -r (logged in as root), then specifying the allowed actions. So far, so good.
Testing the restricted gui as root using sam -f works as it should. But when I log in as a user and try to run sam, sam does not start and returns with:"invalid option -o"... Where does it get the "-o" from? It was not specified anywhere... There is no soft-link or alias set for sam afair.
The other thing that is really weird is, that with some users it runs properly, with some others not.
The newest patches for 11.i have been installed.

Did anyone experience similar probs or does anyone have a clue what to check?

Best regards,
AndrÃ

[KapilRaj]

I have not but it is always better to see the following

As root : -

#which sam

su - user01
which sam

Regds,

Kaps

[André Sorge]

Well, sam resides in /usr/sbin... As it should, probably. Any other ideas?

Thanks in advance,
Andre

[RAC_1]

Anything in samlog?

Login as user. What it says--type sam.
which sam.

Anil

[André Sorge]

There is nothing to see in samlog. Sam immediately cancels at once giving the errormessage "invalid option -o" (as if you would try to run "sam -o", which returns the same error). So it actually does not have the opportunity to log anything.

[Camel_1]

After login to the use, what is result of command "which sam"?

Simon

[André Sorge]

Output is always "/usr/sbin/sam". Therefore, a valid path is set and points to sam correctly.

I will check profiles of the users today. Maybe I find a clue.

Thanks,
AndrÃ

[André Sorge]

Hi there!

Checked .profile of each user for typos and stuff, but nothing unusual. Checked also for aliases again, but nothing special.
Even tested various combinations with the .cf-files in /etc/sam/custom but still the same. So that is not the problem.
Double-checked that filesets of SAM are all configured.

The problem with the illegal option only exists with one user, so maybe there is something hidden in his profile. But were to look?
Is there any way to trace the files which are read during the login process (which vars are set and so on)? I think this is the only way to get out of SAM-hell...

Best regards,
Andre

[Mark Grant · Accepted solution]

/usr/sbin/sam is a shell script. You can put some stuff in there youself as tests. For example, put an "echo $*" to see your arguments though "$@" might be better. Put a "env" to see which environment variables are set. Or put a "set -x" option at the start. Run it like this and compare the results with a user that does work.

[André Sorge]

Hi Mark,

thanks a lot. At startup of SAM I saw that there is a "set -o vi".
I found out that in .shrc of the user there is a line "set -o vi". I removed that line and SAM worked. Creating a .kshrc in the profile with this line worked as well. So my problem is solved at last!

Good job!