Re: IFS effective user

Thank you for explaining this. Nothing I have tested has shed any light
on the IFS file flags so your description really is helpful. It sounds
like I should have used PASE for my tests rather than Qshell. I used the
APIs like qsysetegid, qsyseteuid and qsysetgroups quite a bit. It was
only through a lot of trial and error that I was able to build an
understanding of these APIs because the manual only has a line or two
describing what they do. One difference I did find with the set
effective APIs is that they don't reset authorities when the program
ends like adopt and seem to be cumulative until you do a swap. 

David Morris

>>> botz@xxxxxxxxxx 03/10/05 4:53 PM >>>
I'm a little rusty on this, but here's what I recall...

SETUID is a POSIX concept that I think of as a combination of ADOPT
and
SWAP when applied to executable IFS programs (i.e. PASE).  I don't
recall
for sure but it may cause some other type of behavior when applied to
non-executable IFS files.

It's like adopt in that it uses the authority of the owner of the
file.
It's like SWAP in that it only uses that authority while the program
is
running. I'm pretty sure it only applies to executable programs in IFS
(i.e. PASE).  It is not available for native OS400 programs.

There are also corresponding POSIX APIs that you can use in programs
to
cause them to run under a different ID.  You can combine the functions
of
the "setuid bit" (as it is often referred to in Unix/linux circles). 
For
example, you can set the owner of a PASE program to QSECOFR and then
use
one of the setuid() APIs to set to any arbitrary UID you want.  This is
a
way to reduce the authority that a user might have while running a
particular application.

In the POSIX world (which includes the PASE environment), a program
has
three types of userIDs and groupIDS:
1) real -- the ID underwhich the program was started
2) effective -- the ID under which a program is running (and the one
used
in most* authority checks)
3) saved set ID -- when a change is made to the effective and real
UID/GID
the previous is stored here

There are several flavors of APIs for setting uid (user profiles) and
gid
(group profiles) in PASE.  These include:
sete{u|g}id()     set effective UID,
setr}u|g}id()      set real UID
setre{u|g}id()   set real and effective UIDs
sets{u|g}id()     set the process to the values stored in the saved
setID
note: this list is not exhaustive -- see the info center for more
details.

There are native OS400/i5OS versions of at least some of the these
APIs
too.  These allow you to do the same thing in native programs. The
native
versions of these APIs are the same as the PASE version except they
are
prefixed with "qsy_".  For example,
qsy_seteuid().

All of these APIs use the UID value of the profile as input rather than
the
user profile name.

One of the potentially most valuable uses of these APIs are that they
can
be used to change the user of a process independently of the group
profiles!

For example you can write a program that uses a setegid() API which
effectively makes the user a member of the group ONLY when the
application
is running!

So, aren't you sorry you asked ;-)

Patrick Botz
Senior Technical Staff Member
eServer Security Architect
(507) 253-0917, T/L 553-0917
email: botz@xxxxxxxxxx 


security400-bounces+botz=us.ibm.com@xxxxxxxxxxxx wrote on 03/10/2005
03:43:38 PM:

> Can anyone explain what the set effective user ID/group ID on an IFS
> file does? From the security reference it appears to be related to
> adoption since the SETUID attribute of a program/ifs is discussed in
the
> PA journal entry description. When is it used and what does it do?
The
> help text between green screen and Ops Nav seem to contradict each
> other.
>
> Green Screen:
>
> Set effective user ID (UID) at execution time. This value
> is ignored if the specified object is a directory.  The
> possible values are as follows:
>
> Yes
>     The object owner is the effective user ID (UID) at
>     execution time.
> No
>      The user ID (UID) is not set at execution time.
>
> In Ops Nav:
>
> Use current thread corresponds to green screen Yes and Use object
> values (owner) corresponds to green screen No.
>
> For reference the PA entry says the following:
>
> The type of entry.
> A Change program to adopt owner's authority.
> J Java program adopts owner's authority.
> M Modify object's SETUID, SETGID, or Restricted rename and unlink
> mode indicator.
>
> A program that adopts is set to No.
>
> Thanks,
>
> David Morris