Go Back

How to get currently running dbrs from linux process list

I want to find a list of currently active dbr programs running on a linux server.   I tried using "ps aux", but that only returns the first dbr program that was started.  Any dbr programs chained with a STOP "program" won't show up this way.  Is there a way to get this information on linux?
 

8 Answers
0   | Posted by Russ Judge to Other on 3/4/2019 1:25 PM
Mark Vinten
I believe that when a program issues a STOP to chain to another program, it works very similar to the way that the EXEC command does in shell scripts.  The original process is terminated and a new one is spawned.  Howeer, all of that occurs witin the DBR runtime without recreating a new runtime process because it's effectively a data file to the runtime.  STOP'ing to another filename.dbr effectively closes the handle to the current, opens the next one.

In fact, when you run DBR without any parameters, it asks for the filename.dbr to run.  When you pass the filename.dbr on the command line, it takes the filename prompt away.  So, you can even have DBR processes without ANY parameter indicating what it was running.

So, this effectively means that the original DBR command line is visible via PS AUX (with or without a filename.dbr) but the current filename.dbr may actually be something different.  There is no way for  PS to know this because it's a data file really, not a command line argument to the program. 

The way you could check that out on Linux is using lsof and looking for the filename.dbr that it is has a lock on.  There should really only be one per DBR process. The best method of doing this is just use lsof to find all handles of .dbr, Here is an example of a one liner to get a CSV output of process ID, command and file open
  
lsof -c /dbr/i -Fpcn | grep -iE "((^p.*)|(^c.*)|(^n.*.dbr))" | tr '\n' ',' | sed -e 's/,p/\np/g' | sed -e 's/,$//g' | sed -e 's/^p//g' | sed 's/,[cn]/,/g'

This would produce output such as:
  
27042,dbr,/data1/company1/system1/RTEU01.DBR
27108,dbr,/data1/company1/system2/SOBU02.DBR
28074,dbr,/data1/company1/system2/SOBU02.DBR
28154,dbr,/data1/company1/system3/ROCU08.DBR
28163,dbr,/data1/company1/system4/SOBD04.DBR
28242,dbr,/data1/company1/menu/GHSMEN.DBR
28610,dbr,/data1/company1/menu/GHSMEN.DBR

The one caveat to this, lsof is likely to need superuser level access to obtain all the file handles.  Your best bet would be to write a script that produces the above and allow it to self-elevate via sudo, make the script owned by root, readable by group/world.  Then have a file in /etc/sudoers.d/ that allows sudo access with no passwd to that script.  (You can test $EUID under bash for the effective user ID vs $UID actual user ID).
 

3/8/2019 12:36 PM   0  
Mark Vinten
I should point out that the above commands where tested against Red Hat Enterprise Linux Server release 7.5 (Maipo) with the following program versions:

grep (GNU grep) 2.20
sed (GNU sed) 4.2.2
tr (GNU coreutils) 8.22
lsof v4.87
  
lsof version information:
    revision: 4.87
    latest revision: ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/
    latest FAQ: ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/FAQ
    latest man page: ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/lsof_man
    constructed: Fri Sep 22 10:03:57 EDT 2017
    constructed by and on: mockbuild@x86-030.build.eng.bos.redhat.com
    compiler: cc
    compiler version: 4.8.5 20150623 (Red Hat 4.8.5-16) (GCC)
    compiler flags: -DLINUXV=310000 -DGLIBCV=217 -DHASIPv6 -DHASSELINUX -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -DHAS_STRFTIME -DLSOF_VSTR="3.10.0" -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic
    loader flags: -L./lib -llsof  -lselinux
    system info: Linux x86-030.build.eng.bos.redhat.com 2.6.32-696.10.1.el6.x86_64 #1 SMP Wed Jul 19 08:18:21 EDT 2017 x86_64 x86_64 x86_64 GNU/Linux
    Anyone can list all files.
    /dev warnings are disabled.
    Kernel ID check is disabled.

 

3/8/2019 12:40 PM   0  
Russ Judge
This is an excellent answer--that only caveat being the need for superuser privilege.

I tested it without superuser privilege, and although I get a lot of warnings, it did still give me what I needed on my own user, logged in on a separate session in a dbr program.  I still need to test if I can get that information from a different user, though I suspect the lack of superuser privilege will prevent it.

What scares me about the superuser privilege is for how I intend to use this functionality.  We're in process for converting our legacy traditional Synergy application from OpenVMS, Dibol v. 6.3 to Linux (RedHat), Synergy v. 10.3.3g.  There are certain processes that can only allow one user access to at a time. On OpenVMS, it was easy, since the tools we had listed the actual dbr that was running.  

The information is also useful to know what activities are currently being performed--but generally this information would only be needed by someone who has superuser privilege already, anyhow.

On Linux, from what I can find about using /etc/sudoers.d, I would need to enable the power to elevate to superuser privilege without password for all users, even though I would XCALL SPAWN to the bash script to do so.  Although we are coding to keep the user away from the command line, that possibility would remain do to a program bug or something, thus giving a user with just enough knowledge access to completely reconfigure our system (security issue).  

So, basically, the new question is this--is there a way to restrict the sudo elevation (without password) to only specific scripts?  If not, is there another way to get the basic information needed without su privilege? 

The ideal would be a version of w that also gets the lsof information, without the need for superuser privilege.

It's not the end-of the-world for me if this can't be done--it just means a bit of redesign to come up with a new mechanism for the functionality I'm seeking.

3/8/2019 2:09 PM   0  
Mark Vinten
Yes, and that's exactly what the sudoers is all about.  The script file itself should be owned by root with the permissions 755 (not writable by anyone else).

In the script have something like
  
#!/bin/bash
#
if [ $EUID -ne 0 ]; then
        # Non-Root User?
        /usr/bin/sudo $0 $@
else
        # Root User?
        <elevated commands here>
fi

Create a file in /etc/sudoers.d/ probably based named after your <scriptname> and have contents such as: 
#### <ScriptName> SUDO Access ####

# Create adminstrative access to superuser kill
User_Alias      <ScriptName>USER = %<linux group with access>

# Command alias specification
Cmnd_Alias      <ScriptName>CMD = <full path to script>

# Sudo Access Rules
<ScriptName>USER   ALL = (root) NOPASSWD: <ScriptName>CMD

Say, for example, I wanted to give kill access for any process to a select group of users, I would do 
#### Kill SUDO Access ####

# Create adminstrative access to superuser kill
User_Alias      KILLUSER = %sudokill

# Command alias specification
Cmnd_Alias      KILLCMD = /usr/bin/kill

# Sudo Access Rules
KILLUSER   ALL = (root) NOPASSWD: KILLCMD

If a user is a member of the sudokill linux group, then they can run kill elevated.  In this example, it's the actual kill command, but if it was based on the script above, it means that anyone of that group would have been able to run the script without prefixing it with SUDO and it was have self-elevated. 

Because the script file is owned by root, you are safe in the knowledge that no one can edit that script file. Any command in the script are already hard coded so they can't be abused.  Just make sure you never have a script able to self-elevate and then run any command the user desires within it, that would create a possible breach scenario.

Also make sure you don't allow elevation to commands that can run other commands or shells.  For example, some editors allow you to drop to a shell from within them.

I would also suggest creating a separate file under sudoers.d for example process you are allowing access to as it makes it cleaner to find, edit and maintain than one large file. 

One final thing to mention is.. ALWAYS test any 'sudo su' or other sudo access that you are expecting to work after playing with any sudoers file.  A mistake in one file can have a knock on effect.

3/8/2019 2:31 PM   0  
Russ Judge
Awesome.

Yes, that gives me everything I need.
Thanks.

3/8/2019 3:01 PM   0  
Russ Judge
Just as an addendum--when editing a file in /etc/sudoers.d, be sure to use visudo, not vi.  Lesson learned the hard way here.  Waiting on my sysadmin to reboot the server into recovery mode to delete my file with a syntax error.

visudo checks the syntax of the file before saving, so you wont corrupt your entire server due to a single typo.

3/8/2019 3:40 PM   0  
Mark Vinten
Yes, visudo is good to verify syntax.  But it's also the very reason why I suggested a second session to test your sudo against.  Because sometimes even a correct file can block access as I have found out :)

Never leave superuser, until you are sure you can return!

3/8/2019 3:52 PM   0  
Lloyd Sayman
Here's an os-agnostic alternative to the proposed answer:

I have done this in the past ( I would have to pull the code out of archives to be specific).

Create ISAM file with basic information - user, program being executed, time of program start, PID, server, etc

Add code to the program init routine to update the information at the start of each program.  The init routine is usually in all programs and does the screen or security or commons init.  I haven't seen a system yet that didn't have something like that. 

Create a simple inquiry list to the screen of the information and add it to the menu.

Modify the system menu program to clear the entry for that PID when it logs out.  Add a simple isam clear function to overnight processing to reset the file for the next day.  This can be done as part of the process that reboots the system each night (or not).

It's a pretty simple system and if the init subroutine is universal would only require changing that one routine to implement.  Also the inquiry program would need to be added to the menu - that's the extent of the existing system changes.

The advantage is that no additional permission is required and you are less likely to lock up your server or open the door to superuser abuse. Plus this works even if you decide later on to add additional Linux servers, standalone Windows machines, even non-standard platforms, etc.

Another advantage is that you can record other things besides DBR usage, things that can help with security, performance, etc.  And by adding one line of code that stores the data record to a history file, you now have a log of all activity from all systems in a multi-keyed file for reporting and inquiry purposes.

 

3/12/2019 11:37 AM   0  
Please log in to comment or answer this question.