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

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

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-at-kettleriverconsulting.com
[mailto:info-ingres-bounces-at-kettleriverconsulting.com] On Behalf Of
Steve McElhinney
Sent: 09 October 2008 16:43
To: info-ingres-at-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-at-kettleriverconsulting.com
http://www.kettleriverconsulting.com...fo/info-ingres

On Oct 9, 11:57*am, "Paul Mason" wrote:
> 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-boun...@kettleriverconsulting.com
>
> [mailto:info-ingres-boun...@kettleriverconsulting.com] On Behalf Of
> Steve McElhinney
> Sent: 09 October 2008 16:43
> To: info-ing...@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-Ing...@kettleriverconsulting.comhttp://www.kettleriverconsulting.com/mailman/listinfo/info-ingres- Hide quoted text -
>
> - Show quoted text -

I believe what paul said is correct for all of the std aix shells
today (ksh, ksh93, bsh). you might try testing scripts w/
"whoami" and "who am i" with SUID set to confirm. at least at
aix5.1 they don't follow the bits.

one out might be a backup user defined in sudo (w/o a passwd)

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

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

On Oct 14, 3:24*am, Kristoff 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)

On Oct 14, 5:31 pm, OldSchool 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

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 Database=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 wrote:
> On Oct 14, 5:31 pm, OldSchool 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

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