04-23-2019
Okay, so it's DB2. I think that it is usual for all DB2 users to actually be OS users and you might just need to set up the trust there. You might need to use sudo to run the processes as the nominated OS user that can connect to the database and do the work.
Can you force that through? make sure your sudo rules only allow them to run a specific script as the trusted account that means they can only do what you want, not just a general "Connect me to the database and wheeeee....."
Also, do not allow them to get to the shell prompt as the trusted account else they can probably bypass any rules you want to define. Basically, don't trust them to do anything at all except a very controlled script.
If this is for end users, then you might need to set the sudo rules to use NOPASSWD to permit them without prompting for their own password all the time.
I hope that this helps,
Robin
These 2 Users Gave Thanks to rbatte1 For This Post:
8 More Discussions You Might Find Interesting
1. Shell Programming and Scripting
I'm finding the following command very tedious to type in all the time, so I created a one line bash script called mount.bash with the following contents:
mount -t cifs //mark/C\$ -o unc=//mark\\C$,ip=10.1.1.33,user=Administrator,password=$1 /mnt/mark
I don't like the fact that I have to put... (5 Replies)
Discussion started by: siegfried
5 Replies
2. Shell Programming and Scripting
Hi Unix experts....
I am in the process checking user and root password of more than 1000 servers manulay.
I am very pissed of checking these many servers manualy.
Could some one of you help me how can i check the passwords just by runing some scripts..!
Need Help Guys..! :confused: (5 Replies)
Discussion started by: bullz26
5 Replies
3. Solaris
Ok,
I am trying to install solaris, but I would like as a lean installation as possible (while still having a shread of functionality).
If I chose the minimal install I have little if no utilities to do work on the box.
My question is what installation method do most admins take?
... (7 Replies)
Discussion started by: liven
7 Replies
4. Shell Programming and Scripting
Hi
Most of the shell scripts I am dealing with have to connect to oracle database . The username password is stored in a environment file which sets the variables for username and password . Set user id do not work on AIX so users who will execute these scripts need to have read or execute... (5 Replies)
Discussion started by: clifford
5 Replies
5. Shell Programming and Scripting
Hi All ,
I need to call a script runscript_B.sh on server A, the runscript_B.sh script locating in server B.
The runscript_B.sh in calls another script runscript_A on server A itself.
it seend, i need to be connect from Server A to Server B using ssh.
I have tryed like this in... (3 Replies)
Discussion started by: koti_rama
3 Replies
6. UNIX for Advanced & Expert Users
I've been using various versions of UNIX and Linux since 1993, and I've never run across one that showed your password as you type it in when you log in, or one that stored passwords in plain text rather than encrypted. I'm writing a script for work for a security audit, and two of the... (5 Replies)
Discussion started by: Anne Neville
5 Replies
7. AIX
Does anyone know when AIX started using /etc/security/passwd instead of /etc/passwd to store encrypted passwords? (1 Reply)
Discussion started by: Anne Neville
1 Replies
8. UNIX for Advanced & Expert Users
Hi,
this question is not specially unix related, but I expect advanced and expert unix users to have a solution for this, and I've found no other subforum that fits ;)
what do you use to store accounts, customer ids, ip addresses, users and specially passwords, to access them from... (6 Replies)
Discussion started by: funksen
6 Replies
LEARN ABOUT DEBIAN
opieaccess
OPIEACCESS(5) File Formats Manual OPIEACCESS(5)
NAME
[/etc/]opieaccess - OPIE database of trusted networks
DESCRIPTION
The opieaccess file contains a list of networks that are considered trusted by the system as far as security against passive attacks is
concerned. Users from networks so trusted will be able to log in using OPIE responses, but not be required to do so, while users from net-
works that are not trusted will always be required to use OPIE responses (the default behavior). This trust allows a site to have a more
gentle migration to OPIE by allowing it to be non-mandatory for "inside" networks while allowing users to choose whether they with to use
OPIE to protect their passwords or not.
The entire notion of trust implemented in the opieaccess file is a major security hole because it opens your system back up to the same
passive attacks that the OPIE system is designed to protect you against. The opieaccess support in this version of OPIE exists solely
because we believe that it is better to have it so that users who don't want their accounts broken into can use OPIE than to have them pre-
vented from doing so by users who don't want to use OPIE. In any environment, it should be considered a transition tool and not a permanent
fixture. When it is not being used as a transition tool, a version of OPIE that has been built without support for the opieaccess file
should be built to prevent the possibility of an attacker using this file as a means to circumvent the OPIE software.
The opieaccess file consists of lines containing three fields separated by spaces (tabs are properly interpreted, but spaces should be used
instead) as follows:
Field Description
action "permit" or "deny" non-OPIE logins
address Address of the network to match
mask Mask of the network to match
Subnets can be controlled by using the appropriate address and mask. Individual hosts can be controlled by using the appropriate address
and a mask of 255.255.255.255. If no rules are matched, the default is to deny non-OPIE logins.
SEE ALSO
opie(4), opiekeys(5), opiepasswd(1), opieinfo(1), opiesu(1), opielogin(1), opieftpd(8)
AUTHOR
Bellcore's S/Key was written by Phil Karn, Neil M. Haller, and John S. Walden of Bellcore. OPIE was created at NRL by Randall Atkinson, Dan
McDonald, and Craig Metz.
S/Key is a trademark of Bell Communications Research (Bellcore).
CONTACT
OPIE is discussed on the Bellcore "S/Key Users" mailing list. To join, send an email request to:
skey-users-request@thumper.bellcore.com
7th Edition January 10, 1995 OPIEACCESS(5)