Cktmpl.def, Ingres SUID permissions not inherited by tape ..

There was a problem on Linux where the bash shell didn't (by default)
allow sub-processes to inherit SUID privileges. Since ckpdb is a shell
script (calling dmfjsp). The bash author did this as he considered it a
security risk. However when bash is being used as sh (i.e. /bin/sh is a
link to /bin/bash) then it ought to as sh does. There was a flag or
environment variable you could set to change the behaviour. IIRC it was
changed in a later version so that for bash called as sh it would work
the expected way.

Is it possible you're using a version of bash on AIX? Or possibly the
AIX shell does a similar thing?

Regards
Paul

-----Original Message-----
From: info-ingres-bounces RemoveThis @kettleriverconsulting.com
[mailto:info-ingres-bounces@kettleriverconsulting.com] On Behalf Of
Steve McElhinney
Sent: 09 October 2008 16:43
To: info-ingres RemoveThis @kettleriverconsulting.com
Subject: [Info-Ingres] Cktmpl.def,Ingres SUID permissions not inherited
by tape backup command

We have recently changed our cktmpl.def checkpoint template file
to use the Tivoli /usr/tivoli/tsm/client/ba/bin/dsmc command,
this is for our direct-to-tape backups only.

However we now have problems when running tape checkpoints from non-
ingres users.

We have a database called lamp, owned by user lamp, this user can
checkpoint his own database to disk (the cktmpl.def uses /bin/tar for
disk checkpoints) but not to tape, i.e. checkpoints fail when using
the
new Tivoli dsmc command, the error message indicates that dsmc
doesn't have read permissions to the underlying lamp database files.

The ingres user _can_ checkpoint the lamp database to disk or tape, no
problem.

I hadn't really thought about this before, but the SUID bit on the
iimerge executable (the ckpdb command is basically iimerge) should
overcome this problem and allow a non-priv (in UNIX terms) user to
access files he wouldn't normally be allowed to see.

The problem we have is that the SUID capabilities are not being
inherited by dsmc, they are working fine for (disk checkpoints)
/bin/tar however, and they worked for the previous tape backup
mechanism (netbackup), so this isn't a problem with the permissions on
iimerge.

Can anyone give me any pointers as to why dsmc isn't running with
ingres's SUID permissions?

Version: Ingres 2006, II 9.1.0 (r64.us5/123)

# ls -l iimerge
-rwsr-xr-x 1 ingres sys 11980678 09 Apr 2007 iimerge

TIA
Steve
_______________________________________________
Info-Ingres mailing list
Info-Ingres RemoveThis @kettleriverconsulting.com
http://www.kettleriverconsulting.com/mailman/listinfo/info-ingres
 >> Stay informed about: Cktmpl.def, Ingres SUID permissions not inherited by tape .. 

On Oct 9, 2008, at 11:42 AM, Steve McElhinney wrote:

> ...
> The problem we have is that the SUID capabilities are not being
> inherited by dsmc, they are working fine for (disk checkpoints)
> /bin/tar however, and they worked for the previous tape backup
> mechanism (netbackup), so this isn't a problem with the permissions on
> iimerge.
>
> Can anyone give me any pointers as to why dsmc isn't running with
> ingres's SUID permissions?
>

Most if not all unix-like platforms inhibit SUID on an exec when
LD_LIBRARY_PATH or equivalent is set, because it's a security hole.
This has been a persistent annoyance, and not all dynamic linkers
have offered an alternative. (The SUID inhibition is usually done
by the dynamic linker at program startup.)

Fortunately, more and more platforms allow an rpath (or equivalent)
using $ORIGIN, meaning that the Ingres shared libraries can be
linked relative to the exec-path origin rather than requiring an
absolute link path. I know that linux and solaris allow this,
although I'm not sure whether the change has been incorporated
into the Ingres linking string. (If not, it will be soon, I
hope.) If aix has some sort of rpath/$ORIGIN capability, that
would be the ultimate solution, since it eliminates the need
for the LD_LIBRARY_PATH/LIBPATH/SHLIBPATH setting that so annoys
the dynamic linker.

In the meantime, solutions that occur to me are a) make a copy
of your dmsc program and make it suid ingres; b) copy or link
the Ingres shared libraries to a system location (e.g. /usr/lib)
so that you don't need LD_LIBRARY_PATH or whatever AIX calls it;
c) dig thru the aix ld/ld.so doc to see if there's a way to
define the Ingres $II_SYSTEM/ingres/lib directory as a standard
and trusted directory, again to get rid of LD_LIBRARY_PATH.

Karl
 >> Stay informed about: Cktmpl.def, Ingres SUID permissions not inherited by tape .. 

I don't believe that this is related to the SHELL, in this case
checkpointing to disk would fail too. Also I think we can exclude any
issue with LIBPATH as the iimerge isn't linked dynamically on AIX and
the ckpdb command works fine even when LIBPATH is not set. For further
analysis, I would put the dsmc command in a simple shell script, make
it setuid ingres and then run it as non-ingres. When this doesn't work
either, we can exclude any issue with Ingres, looking for a solution
on the OS side.
From an Ingres point of view, you need to be sure that the checkpoint
template file is owned by ingres, otherwise that template file is
rejected and the checkpoint would fail.
By the way, what is the exact error message you get?

Cheers
Kristoff
 >> Stay informed about: Cktmpl.def, Ingres SUID permissions not inherited by tape .. 

On Oct 14, 3:24 am, Kristoff <kristoff.pic... RemoveThis @ingres.com> wrote:
> I don't believe that this is related to the SHELL....

simple script:

#!/usr/bin/ksh
whoami
who am i


ls -l returns:
-rwsr-sr-x 1 root system 16 Oct 14 11:21 fsm.sh

on HP-UX, I log in and run it, it returns:
root
l00s7m pts/0 Oct 14 11:28
(follows suid bit)

on AIX5.2, I log in, run it, and it returns:
l00s7m
l00s7m pts/4 Oct 14 11:29 (11.64.20.108)
(doesn't follow suid)
 >> Stay informed about: Cktmpl.def, Ingres SUID permissions not inherited by tape .. 

On Oct 14, 5:31 pm, OldSchool <scott.my....TakeThisOut@macys.com> wrote:

> on AIX5.2, I log in, run it, and it returns:
> l00s7m
> l00s7m pts/4 Oct 14 11:29 (11.64.20.108)
> (doesn't follow suid)

That's true. On AIX, the setuid bit of a SHELL script has no effect
(I didn't know this before).
But the efuid is inherited, if the script is called by an executable
running with suid.
So for testing I would use a simple C-program, such as:

int main()
{
system("your_dsmc_command");
return 0;
}

Compile the program, make it suid ingres and call it as non-ingres.
Lets see which error you get(if any)

Regards
Kristoff
 >> Stay informed about: Cktmpl.def, Ingres SUID permissions not inherited by tape .. 

Gents,
Thanks for the detailed replies.
As Kristoff pointed out, the checkpoint to disc (as a non-ingres user)
does work, the checkpoint to tape does not,
so I don't believe it is related to the UNIX shell either,
although I do accept that there are known shell+suid problems with
suspiciously similar symptoms to my issue.

The tape checkpoint can't 'see' the database files because it is
running as lamp (i.e not ingres):
> ANS1087E Access to the specified file or directory is denied.
See the full errors below...

So IMO its not an Ingres problem at all, something about dsmc appears
to 'disable' the suid setting that it is bering called with.
Perhaps dsmc itself attempts to dynamically load some LIBs, which
would effect its SUID status...
how can I tell?


### Checkpoint to disk works ... (uses /bin/tar)
LAMP -=[ LIVE ]=- /lamp/dev:ckpdb stevem2
Wed Oct 22 10:41:07 2008 CPP: Preparing to checkpoint database:
stevem2
Wed Oct 22 10:41:07 2008 CPP: Preparing stall of database, active xact
cnt: 0
Wed Oct 22 10:41:07 2008 CPP: Finished stall of database
beginning checkpoint to disk /lamp/ingres/ckp/default/stevem2 of 1
locations
Wed Oct 22 10:41:09 2008 CPP: Start checkpoint of location:
ii_database to disk:
path = '/lamp/ingres/ckp/default/stevem2'
file = 'c0008001.ckp'
executing checkpoint to disk
ending checkpoint to disk /lamp/ingres/ckp/default/stevem2 of 1
locations
lamp -=[ LIVE ]=- /lamp/dev:

### Checkpoint to tape fails ... (uses dsmc)
LAMP -=[ LIVE ]=- /lamp/dev:ckpdb -mTAPE stevem2
Wed Oct 22 10:47:35 2008 CPP: Preparing to checkpoint database:
stevem2
Wed Oct 22 10:47:35 2008 CPP: Preparing stall of database, active xact
cnt: 0
Wed Oct 22 10:47:35 2008 CPP: Finished stall of database
beginning checkpoint to tape TAPE of 1 locations
Wed Oct 22 10:47:35 2008 CPP: Start checkpoint of location:
ii_database to tape:
device = 'TAPE'
file = 'c0009001.ckp'
Mounting tape 1 ...
DSMC backup: systemG_ingres DB=stevem2 Desc=BA_stevem2_c0009001.ckp
IBM Tivoli Storage Manager
Command Line Backup/Archive Client Interface
Client Version 5, Release 4, Level 1.0
Client date/time: 22-10-2008 10:47:37
(c) Copyright by IBM Corporation and other(s) 1990, 2007. All Rights
Reserved.

Archive function invoked.

Node Name: systemG_INGRES
Session established with server CARPRTXM01: AIX-RS/6000
Server Version 5, Release 5, Level 0.0
Server date/time: 22-10-2008 10:50:20 Last access: 21-10-2008
21:06:32

ANS1087E Access to the specified file or directory is denied
Wed Oct 22 10:47:40 2008 E_DM1101_CPP_WRITE_ERROR Error writing
checkpoint.
Wed Oct 22 10:47:40 2008 E_DM110B_CPP_FAILED Error occurred
checkpointing the database.


On Oct 20, 8:50 am, Kristoff <kristoff.pic....TakeThisOut@ingres.com> wrote:
> On Oct 14, 5:31 pm, OldSchool <scott.my....TakeThisOut@macys.com> wrote:
>
> > on AIX5.2, I log in, run it, and it returns:
> > l00s7m
> > l00s7m      pts/4       Oct 14 11:29     (11.64.20.108)
> > (doesn't follow suid)
>
> That's true. On AIX, the setuid bit of a SHELL script has no effect
> (I didn't know this before).
> But the efuid is inherited, if the script is called by an executable
> running with suid.
> So for testing I would use a simple C-program, such as:
>
> int main()
> {
>   system("your_dsmc_command");
>   return 0;
>
> }
>
> Compile the program, make it suid ingres and call it as non-ingres.
> Lets see which error you get(if any)
>
> Regards
> Kristoff
 >> Stay informed about: Cktmpl.def, Ingres SUID permissions not inherited by tape .. 

I don't have any experience with Tivoli, but if the suggested C-
Program doesn't work either, we can exclude Ingres for sure(and it
would be easier for The Tivolii Guys to understand the problem).
As a workaround you could try to use sudo. You could allow the user
lamp to run the command "ckpdb stevem2" as user ingres - and there
won't be any issue with suid settings.

Regards
Kristoff
 >> Stay informed about: Cktmpl.def, Ingres SUID permissions not inherited by tape ..