AIX

As Jim Mcnamara mentioned above - In AIX /etc/profile is one of the files always processed during login - there is a lot that can be done there.

To get an understanding of what users are trying to do/use as default shell you could add something like

Code:

print  $LOGNAME: `date`: `ps | grep $$` >/to/some/where

... to have a history of who, when, what shell.

Personally, I prefer to not use local .profiles at all. Too many headaches. Users do not 'own' their home directory - only sub-directories, so the admins can always control the content of $HOME/.profile if it even exists.

An additional thought - in some companies it is grounds for immediate dismissal to deliberately go against the company security configuration (showing it can be circumvented should be applauded, but helping others get past policy should not). Along those lines a banner, even though boring to click away - may provide some additional insight to the 'personal' impact of getting on the command line when that is not intended.

Short recap:

[QUOTE=-=XrAy=-;302937118]You are right. I guess the realy safe way is removing this option from bash through modifying the source code and building a custom version.

- download your favourite bash version from https://ftp.gnu.org/gnu/bash/
- modify the shell.c and replace the following line '{ "noprofile", Int, &no_profile, (char **)0x0 },' through ' /* { "noprofile", Int, &no_profile, (char **)0x0 }, */'
- build your custom version

Code:

./configure
make

test it:

Code:

 
./bash --noprofile
./bash: --noprofile: invalid option
Usage:    ./bash [GNU long option] [option] ...
    ./bash [GNU long option] [option] script-file ...
GNU long options:
    --debug
    --debugger
    --dump-po-strings
    --dump-strings
    --help
    --init-file
    --login
    --noediting
    --norc
    --posix
    --rcfile
    --restricted
    --verbose
    --version
Shell options:
    -ilrsD or -c command or -O shopt_option        (invocation only)
    -abefhkmnptuvxBCHP or -o option

Code:

# make a backup from your original bash bevor replacing them ;)
cp bash /bin/bash

Regards

---------- Post updated at 22:56 ---------- Previous update was at 22:51 ----------

i did the things that you suggested and it works perfectly now. the --noprofile option does not exist anymore and also when i tried to run the command that i said earlier the session closes as soon as i enter the password.
however i have some questions about the implementation of this new bash version that i created.
shall i just copy the bash command to my library directory or do i need to do something else first? i mean i need to uninstall bash and install it again? it does not effect the "whole bash package"?

So now your system requires a customized version of bash?

What are you going to do next time bash has a security vulnerability and gets upgraded?

This entire discussion just seems wrong to me. Why not just have users rlogin to this remote system and make their login shell on that system be the utility they are allowed to run. Why give them access to a shell on that system at all?

well actually it doesnt matter what kind of shell you assign to the users. thats why i started this discussion in the first place. for example the user that tried the command to connect to the server and get command line his shell is ksh. but through putty he has the ability to pass a command to the server and choose to run bash shell and use the --noprofile option. so even if i change the login shell of the user he can still do the same.

You seem to have missed what I suggested. Don't use putty and allow the user to choose the command they're going to run on the remote machine.

Have them rlogin to the remote machine and set up their login shell on that remote machine to be the program that you want to run (the program you want to put at the end of the .profile you don't want them to be able to change); not bash, not ksh, not sh; just the program you want them to run on that machine.

As a simple solution i would keep the current package and just overwrite the orginal bash with your custom build, but keep in mind, that after a software update you may need to recopy your bash and you should keep your custom build up date for security reasons.

A more complex solution is to maintain your own bash package (rpm).
- Download a sample rpm-spec file for AIX from Perzl.org (e.g. bash-4.3-13.spec)
- write a custom spec-patch file which disable the option and add them to the bash spec file
- build rpm -ba bash-*.spec your custom rpm

Regards

PS
Please validate the other suggestions (e.g from Don Cragun). Maybe manipulating the bash is to much for that what your need.