DB2 user delete at OS level - db2

If the DB2 uses OS authentication and I delete a DB2 user at the OS level, what will be the impact? Will the DB2 still work fine, and will those privileges that I granted to the user still available after the user is created back?

When asking for help with Db2 please mention your Db2-server platform (Z/os , i-series, Linux/Unix/Windows). The reason is that the answer be different per platform. There are also special tags for your question that you can use to indicate the Db2-platform (db2-zos, db2-400, db2-luw).
If you remove the operating system user the impact is that user can no longer connect to the Db2-database(s) . But any GRANTS that were previously created and stored inside the database(s) will remain unchanged (unless something REVOKES them), even if they will not be used after all pre-existing connections by that removed-operating-system-user are terminated.
For Db2-Linux/Unix/Windows, if you recreate the user in the operating system the previous GRANTS will reapply only if they are still present inside the database and the user successfully reconnects. This behaviour may be different on other platforms.
If the Db2-server is configured with special plugins for security, or uses LDAP or other external tooling then the answer can also be different.

Related

Optimal solution for managing tens of thousands users of a desktop app accessing a PostgreSQL database

I would like to develop a specific app that can be used to access a database developed in PostgreSQL. The app performs calculations and asks for the required data from the database server.
The user can download the app from a website if he has registered. After starting the app, the user has to log in to be able to use it.
Now the question:
What would be the most sensible solution in this example?
To be honest, I don't want to create a separate role for each user.
My idea is that the app only accesses the database via a general role, for example with the name "usership". With this role, a user only has well-defined read access. It is possible that users should also be able to save their own settings or measured values ​​under their user name in certain tables. Access would then only be possible with the correct user name and password, which are specified with each operation on the relevant tables (however, this effort would not be necessary for read-only access to other tables with general data).
The question is whether there are any limits to how many apps can communicate with the database at the same time via the same database credentials / username "usership".
I don't want to have to create a separate DB role for each customer. Somehow that doesn't seem right to me, if only because adding new employees or deleting them means major interventions in the database schema (create / drop role). Basically, the app should do nothing else than a website where several users are logged in at the same time, the only difference being that the app does not run in the browser and everything works either on the client side at the application level or on the database server.
I'm not aware of any limits on sharing of usernames + passwords in postgres. You can have hundreds or thousands of concurrent connections using the same username + password.
There can be issues with many hundreds or thousands of concurrent connections, depending on your database hardware, especially ram.
While Postgres supports thousands of concurrent connections in theory, in practice I've run into memory issues as the # of open connections increases. If this is a problem and a large % of your connections are idle at any one moment, you can add a layer of connection pooling with something like pgbouncer, but keep in mind that adds another process to monitor.
In general, however, I wouldn't recommend this approach. You'd be providing direct, essentially anonymous access to your shared database. I expect it would be difficult to secure your database credentials in the client, and with direct access it should be fairly easy to construct SQL queries that would take down your database server. This would be difficult to monitor or prevent against since all users would be the same and you'd have no way to revoke access in case of abuse (without changing the password for everyone that has access).
From a security standpoint I'd definitely recommend being able to identify your users, monitor their usage separately and revoke access individually. I don't know of any performance issues with having many thousands of separate postgres users/credentials.
-- Scalability --
Using a postgres cluster with read replicas and load balancing (e.g. https://aws.amazon.com/premiumsupport/knowledge-center/requests-rds-read-replicas/) you should be able to scale this horizontally fairly easily if the need arises.

PostgreSQL only clear user password

I am having a big problem, quite difficult to find/search.
I have a server in Ubuntu, where inside that server I have installed:
GITLAB (have all proyect)
POSTGRESSQL (Independent gitlab database is used for a personal project)
TOMCAT with APP WEB (Springboot, this use postgres)
This server is still for testing, it is used for specific specific things (I mean, its use and access is limited and controlled)
I am having various problems:
This server is still for testing, it is used for specific specific things (I mean, its use and access is limited and controlled)
Very frequently, almost every day, the user postgres from the postgresql server "erases" the password. Without anyone doing it manually, "it happens exponentially". I notice why the application stops responding, and then I access postgresql and note that the postgres user has no password.
I looked for many places, and I can't find anything. I really don't know where else to look. If someone passed it to you or has information about it, I would be grateful if you could provide it to me.
------More information added----------
I was looking at the postgres logs, before I have no authentication and I see this.
There are times when no one could have been using the springboot server,
--2020-01-17 00:30:21.286
And also the two log that show before that moment. Could it be something that is deleting my password?
Thank you.
PostgreSQL does not randomly delete its own passwords, and I really doubt Tomcat or Gitlab do either. Indeed they shouldn't even have access to the server as the 'postgres' user or any other superuser, and so shouldn't be able to even if they wanted.
It seems like that there is an intruder in your system. After gaining access they create their own user with their own password. Then disabling your normal superuser from logging on is a common way to try to prevent you from regaining control and kicking them out. Do any users exist that you do not recognize?
The bit of the log file you posted clearly shows someone trying to guess your password, starting at 2:58. You aren't logging IP addresses (%h) so it doesn't show where they are coming from. It doesn't show that they succeed, but unless you have log_connections = on, it wouldn't show successes.

perforce: controlling permissions without involving super user access

We are using perforce in my company and heavily rely on it. I need some suggestion for the following scenario:
Our Depot structure is something like this:
//depot
/product1
/component1
/component2
.
.
/componentN
/*.java
/*.xml
/product2
/component1
/component2
.
.
/componentN
/*.java
/*.xml
Every product has multiple components and every component consist of java or xml or some other program file. Every component has a manager/owner associated with it.
Right now, we have blocked the write permissions for every user and only when it is approved by the manager/owner after code review, we open the write permission for that user for any file/folder to check in. This process becomes a little untidy because the manager/developer have to wait for perforce admin to allow permissions (update protections table of perforce). Also, we give them a window of only 24 hrs to check in (due to agile, which i dont understand much :)), after which we are supposed to block the write access again for that user.
What I am looking for is a mechanism where perforce admins can delegate this responsibility to respective managers/owners without giving them super user or admin access and which automatically disables the write permission after 24 hrs.
Any suggestions ?
Thanks in advance.
There's nothing to do this out of the box, per se.
The closest thing I can think of is if the mainline version of these components were permissioned by a group with an owner. The owner of the group is allowed to add and remove members from the group, thus delegating the permissioning to the "gatekeeper" rather than the admins, themselves.
Let me know if you require further clarification about this.
One common solution is to build a simple tool which reads and writes the protections table, the group memberships, etc., to implement the policies that you desire.
The protections and groups data are not complex in format, and you can easily write a little bit of text-processing code that writes and re-writes these specs according to your needs.
Then install your tool on the server machine in a secure fashion, granting the tool the rights to update the protections table, and have your component administrators use the tool to manage the permissions.
For example, I've seen this done by writing a small web application, in Java or Perl for example, installing that on a web server on a secure machine, and letting the component admins operate that tool through a web interface.
All your tool has to provide is (a) a simple login/logout mechanism for your component admins (the web server may already do this for you), (b) a command that takes a user name and a folder name and grants permission, and (c) a command (or a timer) that removes that permissions subsequently.

Mount notifications on Solaris - as normal user (not root)

Does anyone know of a good (i.e. efficient) way of getting notifications of filesystem mounts/unmounts and/or new/removed devices in Solaris (10), without requiring root?
I'm trying to avoid simply polling /etc/mnttab for new/removed/changed entries, so my first prototype involved using sysevent_subscribe_event to listen for device events, and then using the device information in conjunction with /etc/mnttab to get the mount point. That works well, but sysevent_subscribe_event requires root privileges to run, and I'm not going to have access to the end-user's box, so I can't really elevate their privileges.
I imagine this could be quite tricky, given the restriction of running without root, but any help gratefully received!
Solaris 10 has role based access control so if you have root access to the box you can grant your user the authority to use the service. man roles and auth to get started, also here are two pages that look usefull:
http://www.softpanorama.org/Solaris/Security/solaris_rbac.shtml
http://www.sun.com/software/whitepapers/wp-rbac/wp-rbac.pdf
marc

Finding a legacy firebird/Interbase database password

I have a customer that has an old non-existant application; he had a problem with the company that made the application and they won't disclose his database password. He realized that he signed a contract (back then) where it said that he was sort of "renting" the application and they had no right to disclose anything. This customer found out that he's not the only one with the same problem with that company. He's a Dentist and other dentists with the same old application experienced the same problems when trying to buy a new software and attempted to migrate their patients to the new system.
In either case, he wants to open his little firebird database, so we can at least extract some data to our SQL Servers. I have tried with the default 'masterkey' (which is, in fact, 'masterke' due to the 8 char limit) to no avail.
Now I know he could go legal and try to force the company to release his information, but I want to do it the short way. Does anybody know an app that can brute force/crack a legacy Firebird password?
Thanks.
EDIT: The legacy software is "STOMA-W", I cannot even find it on Internet. They are located in Asturias, Spain.
Firebird does not (yet) store passwords inside the database file.
With this in mind, move the database file to another server where the sysdba password is known.
Old Interbase and Firebird had hardcoded backdoor password you might want to try:
user: politically pass: correct
http://www.theregister.co.uk/2001/01/12/borland_interbase_backdoor_exposed
Provided not for the SYSDBA account, you may reset forgotten passwords for users with FlameRobin. After registering the database server on your localhost, use the Manage users... function in the context menu:
Here you get a list of users with options to delete or view/modify properties. If you click on the properties icon, you enter this dialogue where you simply enter the new password twice:
There is also IBConsole which comes packaged with the InterBase/Firebird SDK. It has similar functions.