Search the FAQ Archives

3 - A - B - C - D - E - F - G - H - I - J - K - L - M
N - O - P - Q - R - S - T - U - V - W - X - Y - Z - Internet FAQ Archives

comp.sys.hp.hpux FAQ
Section - 5.1.1 How do group privileges work?

( Single Page )
[ Usenet FAQs | Web FAQs | Documents | RFC Index | Business Photos and Profiles ]

Top Document: comp.sys.hp.hpux FAQ
Previous Document: 5.1 Auditing and Security
Next Document: 5.1.2 Why are mail files in /var/mail owned by 'daemon' instead of the recipient?
See reader questions & answers on this topic! - Help others by sharing your knowledge

HP-UX 9.0 and later allows special attributes to be associated with
groups, which allows some superuser-like capabilities to be controlled by
defining which groups they are accessible from.   In this way it becomes
possible to distribute superuser accessible commands to other users
without allowing them full access to all other superuser capabilities.
Implicitly, the super-user is a member of ALL groups.

This allows some (slight) relaxing of UNIX's 'all or nothing' approach to
distributing privileged capabilities.  Privileged groups are an HP-UX-
specific feature.

Here is a list of group privileges available in various releases of HP-UX,
along with a brief description of the system capabilities that they

9.0 and later
  o PRIV_RTPRIO - can use rtprio() to set real-time priorities (see
                  rtprio(1) and rtprio(2))

  o PRIV_MLOCK - can use plock() to lock process text and data into
                 memory, and the shmctl() SHM_LOCK function to lock shared
                 memory segments (see plock(2) and shmctl(2))

  o PRIV_CHOWN - can use chown() to change file ownerships (see chown(1)
                 and chown(2))

  o PRIV_LOCKRDONLY - can use lockf() to set locks on files that are open
                      for reading only (see lockf(2))

  o PRIV_SETRUGID - can use setuid() and setgid() to change, respectively,
                    the real user ID and real group ID of a process (see
                     setuid(2) and setgid(2))

10.0 and later
  o PRIV_MPCTL - can use mpctl() to change the processor assignment,
                 locality domain assignment, or launch policy of another
                 process (see mpctl(2))

  o PRIV_RTSCHED - can use sched_setparam() and sched_setscheduler() to
                   set POSIX.4 real-time priorities (see rtsched(1) and

  o PRIV_SERIALIZE - can use serialize() to force the target process to
                     run serially with other processes that are also
                     marked by this system call (see serialize(1),

11.0 and later
  o PRIV_SPUCTL - can use spuctl() (undocumented) to control SPU
                  allocation (see /usr/include/sys/spuctl.h)

11i and later
  o PRIV_FSSTHREAD - can use fss() (undocumented) to control fair share
                     scheduler (see /usr/include/sys/fss.h)

  o PRIV_PSET - can use pset_*() (undocumented) to control processor set
                (see /usr/include/sys/pset.h)

Group privileges can be granted to individual groups, or globally (ie - to
all groups, and hence, all users).

Although this doesn't appear to be covered by any HP documentation, it
appears that users are assigned the group privileges associated with
their primary group ID, and of all secondary groups defined within file

By default, the setprivgrp command changes are no longer effective once
you reboot your system.  However, you can execute the command
'/sbin/init.d/set_prvgrp start' to ensure that the privilege group changes
are permanent.  /sbin/init.d/set_prvgrp runs '/usr/sbin/setprivgrp -f
/etc/privgroup'.  The /etc/privgrp file should contain one or more lines
in the following format:

  groupname [privileges]
  -g [privileges]
  -n [privileges]

Each line in privgrp must end with a newline character.  The syntax for
'groupname' and 'privileges' is described in the "Options and Arguments"
section of setprivgrp(1M).

If the /etc/privgrp is not found when the system boots, the PRIV_CHOWN
privilege is automatically enabled globally (as if '-g CHOWN' was
specified).  Furthermore, by default, /etc/privgrp does NOT exist.

The group privilege feature is often used to secure the chown command,
which has the potential to be misused.  The chown command may be used to
change the owner ID of a file (or files) to another specified owner.  As
mentioned above, by default, PRIV_CHOWN is granted globally.  Hence, the
chown command may be used by any user to assign ownership of their own
files to any other user, including root.

For example, HP-UX's disk-space accounting facility may be used to report
the total disk usage of all users.  It's possible for users to conceal
their total disk usage by using the chown command to assign the ownership
of their own files to other users.

On BSD-derived UNIX implementations, chown usage is limited to super-
users only.  By removing the global group privilege PRIV_CHOWN using the
setprivgrp command, it's also possible to close this loophole on HP-UX,
by limiting usage of the chown command to users who are members of
specified groups only.  This can be achieved as follows:

  # echo "-n CHOWN" >>/etc/privgrp
  # /sbin/init.d/set_prvgrp start

HP-UX documentation recommends that you not rely on the privileged group
mechanism to restrict access to the setuid and setgid system calls.
They do not guarantee that group privileges will be supported by future
releases of HP-UX.

For more information, see getprivgrp(1), setprivgrp(1M), getprivgrp(2),
setprivgrp(2), and privgrp(4).

User Contributions:

Comment about this article, ask questions, or add new information about this topic:


Top Document: comp.sys.hp.hpux FAQ
Previous Document: 5.1 Auditing and Security
Next Document: 5.1.2 Why are mail files in /var/mail owned by 'daemon' instead of the recipient?

Single Page

[ Usenet FAQs | Web FAQs | Documents | RFC Index ]

Send corrections/additions to the FAQ Maintainer:

Last Update March 27 2014 @ 02:11 PM