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
> _______________________________________________
> This is the Security Administration on the AS400 / iSeries
> (Security400) mailing list
> To post a message email: Security400@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/security400
> or email: Security400-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/security400.
>


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2021 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.