The use of the auth-group (and auth-user) ? - SCO

This is a discussion on The use of the auth-group (and auth-user) ? - SCO ; First let me apolegize for asking this question here, rather than looking at the system's documentation. The answer is simple, I don't have a SCO-system - and I'm not about to get one - which pretty much limits me to ...

+ Reply to Thread
Results 1 to 12 of 12

Thread: The use of the auth-group (and auth-user) ?

  1. The use of the auth-group (and auth-user) ?

    First let me apolegize for asking this question
    here, rather than looking at the system's
    documentation. The answer is simple, I don't
    have a SCO-system - and I'm not about to get
    one - which pretty much limits me to look on
    the net, and the answer I've gotten so far (without
    actually asking) is non-conclusive.

    The reason I ask, is that I'm toying with the idea of
    making a list of various system/psaudo-users and
    system-groups; and what they do, what they
    should own, who should be member/which groups
    they should belong to, and why it's a good idea...

    My question is, what does the auth-group and
    auth-user (I believe there is one) do?

    As I understand it, members of the auth-group
    can modify the passwd-file -- change information,
    (probably) change passwd, lock accounts; and
    (probably) add and remove users... is that about
    right?

    What about the auth-user? Does the group have
    direct write-access (e.g. with an editor) to /etc/
    passwd?

    What do they (auth user/group) own? With what
    permission? What should they run? Who should
    be member? Is there also a shadowed password
    file... if it is, is it owned/grouped by 'auth' or does it
    has it's own group (eg. 'shadow')? Does 'auth'
    own /etc ?

    +++

    So a general question about SCO... I've mostly
    used (yes, I know it's like reading from "Satanic
    Verses" in a mosque ;-) *sigh* Linux. Linux more
    and more have gone away from seperate users
    and groups; almost everything belongs to
    root:root and most things are run by root. The
    exception is /dev, where there are groups of
    devices (disk, audio, video) -- rather than the
    traditional 'sys'.

    'adm' user and group is no longer used, and
    don't own the log-directory... 'sys' no longer
    owns any devices, nor the /dev itself... the
    'bin' group no longer owns the (s)bin
    directories - nor the executables under
    them - nor does the 'bin' user own or run
    anything.

    On many distros, the 'operator' user and/or
    group have been removed, and own
    nothing -- AFAIK, this user/group should be
    used to give extra privliges users doing stuff
    like back-ups, starting/stopping printers,
    (un)mounting disk/CDs -- and working on the
    console (sound-card, etc) -- without having
    to go full 'root'.

    How is it for SCO; are the usage of the users
    and groups more reasonable? I understand
    most executables are owned root:bin or bin:bin
    (btw, why the difference?) and that even some
    config-files are owned by bin:bin? How about
    the bin-directories -- root:bin or bin:bin? What
    about sys-group, does it own /dev and the
    devices in SCO? (Btw, is there a sys-*user*?)
    What about logs and various logging-processes?
    Are most still owned by root:adm or adm:adm; and
    perhaps run as adm?

    Any thoughts about this -- as well as directions
    to good existing documents about these
    things (the description/usage of users and
    groups) -- would be greatly appriciated...

    (Didn't know I was quite so frustrated with Linux...
    how much does cheapast SCO-license cost? :-)

    -Koppe


  2. Re: The use of the auth-group (and auth-user) ?

    Koppe wrote:

    > (Didn't know I was quite so frustrated with Linux...


    Besides SCO you may also want to look at FreeBSD.

    I've come to a conclusion that Ubuntu makes excellent desktop & laptop OS's.

    But if *I* need a server, freeBSD.

    About your questions about bin group ownership, freeBSD uses the wheel group in
    the manner you were asking about.

    FreeBSD just makes better sence in that userland programs are not tied to kernel
    versions.

    Here's a place to get started about FreeBSD security
    http://www.freebsd.org/doc/en_US.ISO...g-freebsd.html

    In fact that's the one thing you will notice about FreeBSD is the documentation.

    --
    Walter


  3. Re: The use of the auth-group (and auth-user) ?

    In article <7_6dnf0Oz7P05cbbnZ2dnUVZ_j2dnZ2d@ctc.net>,
    Walter Vaughan wrote:
    >Koppe wrote:
    >
    >> (Didn't know I was quite so frustrated with Linux...


    >Besides SCO you may also want to look at FreeBSD.


    >I've come to a conclusion that Ubuntu makes excellent desktop &
    >laptop OS's.


    I've just gotten a set of 3 CDs of Unbuntu to take a look.
    It is SO NICE that you can get free CDs instead of having to take
    the time to DL the ISOs and then burn them.

    The caveat for the free CDs says depending upon the volume
    it could take 6 to 10 weeks to arrive. Mine arrived in two
    week via air mail from Belgium.

    In case anyone wants to know where to get the free CDs
    go to http://www.canonical.com

    They are a support house that you pay for support, but they give
    away the CDs free.

    >But if *I* need a server, freeBSD.


    Agree most heartily.

    >About your questions about bin group ownership, freeBSD uses the
    >wheel group in the manner you were asking about.


    And he also said that root runs most things. I think he does
    not understand that while root:root are the permission for
    most of the system files they are NOT run by root - but by the user
    who runs them.

    There are not that many files that are SUID root - so the OP
    doesn't have a full understanding of Unix or Unix like systems.

    >FreeBSD just makes better sence in that userland programs are not
    >tied to kernel versions.


    And the fact that the ports system lets you build everyting you
    want you don't run into the library incompatibility problems
    that often pop up when installing RPMs in Linux.

    >Here's a place to get started about FreeBSD security
    >http://www.freebsd.org/doc/en_US.ISO...g-freebsd.html


    >In fact that's the one thing you will notice about FreeBSD is the
    >documentation.


    And one thing I've noticed about many Linux man pages is that
    they have often just used the FreeBSD/BSD man pages with a
    global substitution of Linux for FreeBSD >>HOWEVER<< they left
    the original path names in the man pages that aren't the ones
    used in Linux.

    Bill
    --
    Bill Vermillion - bv @ wjv . com

  4. Re: The use of the auth-group (and auth-user) ?

    On 28 May, 21:56, Koppe wrote:
    > First let me apolegize for asking this question
    > here, rather than looking at the system's
    > documentation. The answer is simple, I don't
    > have a SCO-system - and I'm not about to get
    > one - which pretty much limits me to look on
    > the net, and the answer I've gotten so far (without
    > actually asking) is non-conclusive.


    SCO doc is available at:

    http://www.sco.com/support/docs/

    > (Didn't know I was quite so frustrated with Linux...
    > how much does cheapast SCO-license cost? :-)


    You can download the ISO for OpenServer 6.0.0 from:

    http://www.sco.com/support/update/do...se.php?rid=161

    You can install this with a built-in 60 dya evaluation license.

    JOhn




  5. Re: The use of the auth-group (and auth-user) ?

    On 28 May, 21:56, Koppe wrote:
    > First let me apolegize for asking this question
    > here, rather than looking at the system's
    > documentation. The answer is simple, I don't
    > have a SCO-system - and I'm not about to get
    > one - which pretty much limits me to look on
    > the net, and the answer I've gotten so far (without
    > actually asking) is non-conclusive.


    The SCO doc is available online at:

    http://www.sco.com/support/docs/

    > (Didn't know I was quite so frustrated with Linux...
    > how much does cheapast SCO-license cost? :-)


    An OpenServer 6.0.0 ISO is available to download from:

    http://www.sco.com/support/update/do...se.php?rid=161

    You can install and choose the built-in 60 day evaluation license.

    John




  6. Re: The use of the auth-group (and auth-user) ?

    On May 29, 5:35 am, b...@wjv.com (Bill Vermillion) wrote:
    > In article <7_6dnf0Oz7P05cbbnZ2dnUVZ_j2dn...@ctc.net>,
    > Walter Vaughan wrote:
    >
    > >Koppe wrote:


    > Agree most heartily.
    >
    > >About your questions about bin group ownership, freeBSD uses the
    > >wheel group in the manner you were asking about.


    But auth isn't GID #0, is it? The buildt-in privliged group (called
    wheel
    in FreeBSD and root in Linux)... The group that allow users to
    acend to root? I thought it was more like the shadow-group, except
    that it had extra-privliges for *all* authentication-files -- and
    perhaps
    the command for changing-password utilized this (by being run
    SGID auth)...

    > And he also said that root runs most things. I think he does
    > not understand that while root:root are the permission for
    > most of the system files they are NOT run by root - but by the user
    > who runs them.
    >
    > There are not that many files that are SUID root - so the OP
    > doesn't have a full understanding of Unix or Unix like systems.


    I am of course aware of that... I was thinking about things
    being started by the OS itself (not by users) -- various daemons.
    Unecessery many are run as root (well, I guess it *is* necessery,
    but only because everything is owned/grouped by root:root in the
    first place).

    The trend in Linux seems that almost all daemons are run
    by/as root. If the directories, files and devices had been
    set up more carefully -- and the various system users
    and groups had actually been utilized (e.g. users put in the
    right groups); then there shouldn't be a problem running things
    as less-priviliged -- safer -- users.

    Like running the system-logger (or at least *some* logger) as adm
    instead of as root... (necessery permission could be given by making
    adm a member of the root-*group* GID #0)... in any case, /var/log
    and most of the files under it, should have adm as group. Even
    daemons for printers and mail are often being run as root.

    I of course understand it's easier to run everything as root,
    rather than having to make sure of permissions of files, devs
    and dirs -- and which users are in what groups; but the point of
    the whole division into user and groups, is to ensure that users
    and processes only can access what they *actually* _need_.

    Processes that's only supposed to find out what manual-pages
    contains, collect and write log-entries, or list which executables
    are with SUID/SGID; doesn't *really* need full access to everything
    on the whole system. man:adm, adm:adm (w/adm in root-group),
    and bin:adm should be sufficent (thus runing as man, adm and bin).

    > >FreeBSD just makes better sence in that userland programs are not
    > >tied to kernel versions.


    I have actually tried FreeBSD (right now too actually).

    I still would like to know more about the auth-group (and auth-user?),
    and if SCO has a more reasonable division of directories and files
    into
    groups and perhaps users.

    Btw, I've seen some listings of files in SCO; is there a reason why
    some
    executables are root:bin and others bin:bin? With binaries without
    the SUID bit, what is the difference?

    -Koppe


  7. Re: The use of the auth-group (and auth-user) ?

    In article <1180450206.342741.220300@p47g2000hsd.googlegroups. com>,
    Koppe wrote:
    >On May 29, 5:35 am, b...@wjv.com (Bill Vermillion) wrote:
    >> In article <7_6dnf0Oz7P05cbbnZ2dnUVZ_j2dn...@ctc.net>,
    >> Walter Vaughan wrote:


    >> >Koppe wrote:


    >> Agree most heartily.


    >> >About your questions about bin group ownership, freeBSD uses the
    >> >wheel group in the manner you were asking about.


    >But auth isn't GID #0, is it? The buildt-in privliged group
    >(called wheel in FreeBSD and root in Linux)... The group that
    >allow users to acend to root? I thought it was more like
    >the shadow-group, except that it had extra-privliges for
    >*all* authentication-files -- and perhaps the command for
    >changing-password utilized this (by being run SGID auth)...


    >> And he also said that root runs most things. I think he does
    >> not understand that while root:root are the permission for
    >> most of the system files they are NOT run by root - but by the user
    >> who runs them.


    >> There are not that many files that are SUID root - so the OP
    >> doesn't have a full understanding of Unix or Unix like systems.


    >I am of course aware of that... I was thinking about things
    >being started by the OS itself (not by users) -- various daemons.
    >Unecessery many are run as root (well, I guess it *is* necessery,
    >but only because everything is owned/grouped by root:root in the
    >first place).


    You didn't make that clear when you said 'most things are run by
    root'.

    But being owned/grouped by root:root doesn't mean they have to be
    run by root if the 'other' permission are executeable.

    >The trend in Linux seems that almost all daemons are run
    >by/as root. If the directories, files and devices had been
    >set up more carefully -- and the various system users
    >and groups had actually been utilized (e.g. users put in the
    >right groups); then there shouldn't be a problem running things
    >as less-priviliged -- safer -- users.


    A good idea on directories is 'man hier' and they do differ between
    Linux and FreeBSD. The latter sticks to the idea more closely
    where virtually all non-OS files are in the /usr/local hierarchy,

    However in FreeBSD many programs that are run at startup are
    run under other users so that in the case something/someone breaks
    a program/application, they only have the privledges of that
    program. For instances sendmail has two separate ownership under
    which it runs, so if it is broken you only get the ssmsp and/or
    mailnull privledges.

    >Like running the system-logger (or at least *some* logger) as adm
    >instead of as root... (necessery permission could be given by making
    >adm a member of the root-*group* GID #0)... in any case, /var/log
    >and most of the files under it, should have adm as group. Even
    >daemons for printers and mail are often being run as root.


    >I of course understand it's easier to run everything as root,
    >rather than having to make sure of permissions of files, devs
    >and dirs -- and which users are in what groups; but the point of
    >the whole division into user and groups, is to ensure that users
    >and processes only can access what they *actually* _need_.


    Making things 'easier' often leads to security holes - sometimes
    not envisioned. And as to the user/group methodology they are
    not the same under BSD [starting with the originals going back
    to the 1970's] and it's descendants as they are under the Unix
    derived systems. That tends to confuse newcomers to that.
    And a typical default FreeBSD system has separate groups
    FOR EACH USER. That can be changed to put them all in one group
    but it many respects the one group per user can eliminate problems.

    >Processes that's only supposed to find out what manual-pages
    >contains, collect and write log-entries, or list which executables
    >are with SUID/SGID; doesn't *really* need full access to everything
    >on the whole system. man:adm, adm:adm (w/adm in root-group),
    >and bin:adm should be sufficent (thus runing as man, adm and bin).


    I do think the Linux [ at least on the SuSE system I just checked]
    of having 'man' run SUID 'root' is wrong. The FBSD runs
    SUID to user 'man' - so that goes along with your ideas.
    IMO nothing should be run as root unless absolutley neccessary.

    >> >FreeBSD just makes better sence in that userland programs are not
    >> >tied to kernel versions.


    >I have actually tried FreeBSD (right now too actually).


    The changes over the past couple of years - moving from the 4.x
    into the 6.x have been quite large and there were a few stumbling
    blocks in the 5.x along the way. 7 is 'bleeding edge' - almost
    'pre-bleeding-edge' so it can change hourly.

    >I still would like to know more about the auth-group (and
    >auth-user?), and if SCO has a more reasonable division of
    >directories and files into groups and perhaps users.


    >Btw, I've seen some listings of files in SCO; is there a reason
    >why some executables are root:bin and others bin:bin? With
    >binaries without the SUID bit, what is the difference?


    >-Koppe


    Bill

    --
    Bill Vermillion - bv @ wjv . com

  8. Re: The use of the auth-group (and auth-user) ?

    On May 29, 7:50 am, Koppe wrote:
    > On May 29, 5:35 am, b...@wjv.com (Bill Vermillion) wrote:
    >
    > > In article <7_6dnf0Oz7P05cbbnZ2dnUVZ_j2dn...@ctc.net>,
    > > Walter Vaughan wrote:

    >
    > > >Koppe wrote:

    > > Agree most heartily.

    >
    > > >About your questions about bin group ownership, freeBSD uses the
    > > >wheel group in the manner you were asking about.

    >
    > But auth isn't GID #0, is it? The buildt-in privliged group (called
    > wheel
    > in FreeBSD and root in Linux)... The group that allow users to
    > acend to root? I thought it was more like the shadow-group, except
    > that it had extra-privliges for *all* authentication-files -- and
    > perhaps
    > the command for changing-password utilized this (by being run
    > SGID auth)...
    >
    > > And he also said that root runs most things. I think he does
    > > not understand that while root:root are the permission for
    > > most of the system files they are NOT run by root - but by the user
    > > who runs them.

    >
    > > There are not that many files that are SUID root - so the OP
    > > doesn't have a full understanding of Unix or Unix like systems.

    >
    > I am of course aware of that... I was thinking about things
    > being started by the OS itself (not by users) -- various daemons.
    > Unecessery many are run as root (well, I guess it *is* necessery,
    > but only because everything is owned/grouped by root:root in the
    > first place).
    >
    > The trend in Linux seems that almost all daemons are run
    > by/as root. If the directories, files and devices had been
    > set up more carefully -- and the various system users
    > and groups had actually been utilized (e.g. users put in the
    > right groups); then there shouldn't be a problem running things
    > as less-priviliged -- safer -- users.
    >
    > Like running the system-logger (or at least *some* logger) as adm
    > instead of as root... (necessery permission could be given by making
    > adm a member of the root-*group* GID #0)... in any case, /var/log
    > and most of the files under it, should have adm as group. Even
    > daemons for printers and mail are often being run as root.
    >
    > I of course understand it's easier to run everything as root,
    > rather than having to make sure of permissions of files, devs
    > and dirs -- and which users are in what groups; but the point of
    > the whole division into user and groups, is to ensure that users
    > and processes only can access what they *actually* _need_.
    >
    > Processes that's only supposed to find out what manual-pages
    > contains, collect and write log-entries, or list which executables
    > are with SUID/SGID; doesn't *really* need full access to everything
    > on the whole system. man:adm, adm:adm (w/adm in root-group),
    > and bin:adm should be sufficent (thus runing as man, adm and bin).
    >
    > > >FreeBSD just makes better sence in that userland programs are not
    > > >tied to kernel versions.

    >
    > I have actually tried FreeBSD (right now too actually).
    >
    > I still would like to know more about the auth-group (and auth-user?),
    > and if SCO has a more reasonable division of directories and files
    > into
    > groups and perhaps users.
    >
    > Btw, I've seen some listings of files in SCO; is there a reason why
    > some
    > executables are root:bin and others bin:bin? With binaries without
    > the SUID bit, what is the difference?
    >
    > -Koppe


    You're being a bit obscure about your purpose, which makes it hard to
    provide an answer.

    User and group "auth" are merely used to mark ownership and
    permissions of SCO's authentication subsystem. For more information
    see the man page for "tcbck." The kernel consults the authentication
    database to control user access to, as you say, "what they actually
    need." See, generally, the man page for "usermod." Effectively it's
    an early ACL system.

    There is no SCO analog to the Linux "wheel" group. SCO got
    that one right. Making execution rights depend upon a group name is a
    violation of database normal design.


    SCO has an "asroot" facility, which see. Asroot can be used somewhat
    like "sudo" to run various commands as root. It works, of course,
    through the authentication subsystem.

    As a correction, the daemons aren't launched by the OS. They're
    launched by scripts. Although it's arguably a Linux & SCO weakness
    that all these scripts are launched by the init process in the "root"
    context, they can and some do downgrade themselves by running "su". As
    a simple example, the telnet or ssh daemons run as root. But when a
    particular user logs in, that instance downgrades to that user's
    rights.

    SUID isn't that widespread on most systems. For example, the "su"
    command is SUID root for much the same reason that the telnetd runs as
    root. But a user without "su" authorization isn't allowed to execute
    it regardless.

    --RLR


  9. Re: The use of the auth-group (and auth-user) ?

    On 2007-05-29, Bill Vermillion wrote:
    >
    > And one thing I've noticed about many Linux man pages is that
    > they have often just used the FreeBSD/BSD man pages with a
    > global substitution of Linux for FreeBSD >>HOWEVER<< they left
    > the original path names in the man pages that aren't the ones
    > used in Linux.


    This is a side effect of the different development models: the BSDs
    are true operating systems whereas Linux is a kernel and the
    distributions are similar but subtly different OSes. Although you
    are not necessarily guaranteed the latest version of any particular
    tool, the fact that they are included as part of the package means
    that the development teams do take a little more pride in the
    userland. Things like man pages will be supplied if they are
    lacking.

    An example of this is that a few days ago I reported a problem with
    NetBSD's fmt - basically a documentation issue. The development
    team are looking at it now and debating whether to amend the man
    page or borrow the Open/FreeBSD equivalent. It _will_ be fixed -
    for all future versions - and it will stay fixed. Little things
    like that are often lacking in the Linux distros. Even if one
    chooses to fix a similar problem you can still be encountering it
    much later with other distros.

    --
    Andrew Smallshaw
    andrews@sdf.lonestar.org

  10. Re: The use of the auth-group (and auth-user) ?

    In article <1180457964.496188.169450@g37g2000prf.googlegroups. com>,
    ThreeStar wrote:
    >On May 29, 7:50 am, Koppe wrote:
    >> On May 29, 5:35 am, b...@wjv.com (Bill Vermillion) wrote:


    [lots deleted - wjv]


    >> I still would like to know more about the auth-group (and
    >> auth-user?), and if SCO has a more reasonable division of
    >> directories and files into groups and perhaps users.


    >> Btw, I've seen some listings of files in SCO; is there a reason
    >> why some executables are root:bin and others bin:bin? With
    >> binaries without the SUID bit, what is the difference?


    >> -Koppe


    >You're being a bit obscure about your purpose, which makes it hard to
    >provide an answer.


    >User and group "auth" are merely used to mark ownership and
    >permissions of SCO's authentication subsystem. For more
    >information see the man page for "tcbck." The kernel consults
    >the authentication database to control user access to, as you
    >say, "what they actually need." See, generally, the man page for
    >"usermod." Effectively it's an early ACL system.


    >There is no SCO analog to the Linux "wheel" group. SCO got
    >that one right. Making execution rights depend upon a group name is a
    >violation of database normal design.


    It's BSD that has the 'wheel' group. And the groups in *BSD are
    quite different than those in Unix or Linux. The group 'wheel'
    in the *BSDs is just another name for 'root' as there is NO 'root'
    group. The real difference is that a user has to be in the 'wheel'
    group to be able to 'su' to root. It's supposed to be more secure
    that way.

    However I have had some design problems with the way it is
    implemented, as there are holes in the concept from my POV.
    It's basically nothing more than a two-password way of getting
    root privledges - but when I've questioned it no one I've received
    no good reasons why it isn't more secure.

    At it is installed 'wheel' is just the name of
    the group that 'root' is in, and there are no other users
    in 'wheel' except group when you install it. If you change the
    name of group 0 in /etc/groups to wheel it will look the same as
    in *BSD. And if you remove group 0, any user can su to root.

    >SCO has an "asroot" facility, which see. Asroot can be used somewhat
    >like "sudo" to run various commands as root. It works, of course,
    >through the authentication subsystem.


    Which is lot better than letting a user su to root as you can
    restrict their privledges.

    >As a correction, the daemons aren't launched by the OS. They're
    >launched by scripts. Although it's arguably a Linux & SCO weakness
    >that all these scripts are launched by the init process in the "root"
    >context, they can and some do downgrade themselves by running "su". As
    >a simple example, the telnet or ssh daemons run as root. But when a
    >particular user logs in, that instance downgrades to that user's
    >rights.


    >SUID isn't that widespread on most systems. For example, the "su"
    >command is SUID root for much the same reason that the telnetd runs as
    >root. But a user without "su" authorization isn't allowed to execute
    >it regardless.
    >
    >--RLR



    Bill
    --
    Bill Vermillion - bv @ wjv . com

  11. Re: The use of the auth-group (and auth-user) ?

    On May 29, 8:15 pm, b...@wjv.com (Bill Vermillion) wrote:
    > In article <1180457964.496188.169...@g37g2000prf.googlegroups. com>,
    >
    > ThreeStar wrote:
    > >On May 29, 7:50 am, Koppe wrote:
    > >> On May 29, 5:35 am, b...@wjv.com (Bill Vermillion) wrote:

    >
    > [lots deleted - wjv]
    >
    >
    >
    > >> I still would like to know more about the auth-group (and
    > >> auth-user?), and if SCO has a more reasonable division of
    > >> directories and files into groups and perhaps users.
    > >> Btw, I've seen some listings of files in SCO; is there a reason
    > >> why some executables are root:bin and others bin:bin? With
    > >> binaries without the SUID bit, what is the difference?
    > >> -Koppe

    > >You're being a bit obscure about your purpose, which makes it hard to
    > >provide an answer.
    > >User and group "auth" are merely used to mark ownership and
    > >permissions of SCO's authentication subsystem. For more
    > >information see the man page for "tcbck." The kernel consults
    > >the authentication database to control user access to, as you
    > >say, "what they actually need." See, generally, the man page for
    > >"usermod." Effectively it's an early ACL system.
    > >There is no SCO analog to the Linux "wheel" group. SCO got
    > >that one right. Making execution rights depend upon a group name is a
    > >violation of database normal design.

    >
    > It's BSD that has the 'wheel' group. And the groups in *BSD are
    > quite different than those in Unix or Linux. The group 'wheel'
    > in the *BSDs is just another name for 'root' as there is NO 'root'
    > group. The real difference is that a user has to be in the 'wheel'
    > group to be able to 'su' to root. It's supposed to be more secure
    > that way.
    >
    > However I have had some design problems with the way it is
    > implemented, as there are holes in the concept from my POV.
    > It's basically nothing more than a two-password way of getting
    > root privledges - but when I've questioned it no one I've received
    > no good reasons why it isn't more secure.
    >
    > At it is installed 'wheel' is just the name of
    > the group that 'root' is in, and there are no other users
    > in 'wheel' except group when you install it. If you change the
    > name of group 0 in /etc/groups to wheel it will look the same as
    > in *BSD. And if you remove group 0, any user can su to root.
    >
    > >SCO has an "asroot" facility, which see. Asroot can be used somewhat
    > >like "sudo" to run various commands as root. It works, of course,
    > >through the authentication subsystem.

    >
    > Which is lot better than letting a user su to root as you can
    > restrict their privledges.
    >
    > >As a correction, the daemons aren't launched by the OS. They're
    > >launched by scripts. Although it's arguably a Linux & SCO weakness
    > >that all these scripts are launched by the init process in the "root"
    > >context, they can and some do downgrade themselves by running "su". As
    > >a simple example, the telnet or ssh daemons run as root. But when a
    > >particular user logs in, that instance downgrades to that user's
    > >rights.
    > >SUID isn't that widespread on most systems. For example, the "su"
    > >command is SUID root for much the same reason that the telnetd runs as
    > >root. But a user without "su" authorization isn't allowed to execute
    > >it regardless.

    >
    > >--RLR

    >
    > Bill
    > --
    > Bill Vermillion - bv @ wjv . com


    FWIW the PAM module pam_wheel.so controls su privileges and the
    "wheel" group. Linux distros vary on the default configuration. In
    the Oracle (!) Red Hat Enterprise clone I'm looking at just now it's
    commented out of /etc/pam.d/su so "wheel" is just another group on
    this system.

    --RLR


  12. Re: The use of the auth-group (and auth-user) ?

    On May 29, 8:15 pm, b...@wjv.com (Bill Vermillion) wrote:
    > In article <1180457964.496188.169...@g37g2000prf.googlegroups. com>,
    >
    > ThreeStar wrote:
    > >On May 29, 7:50 am, Koppe wrote:
    > >> On May 29, 5:35 am, b...@wjv.com (Bill Vermillion) wrote:

    >
    > [lots deleted - wjv & rlr]
    >
    > It's BSD that has the 'wheel' group. And the groups in *BSD are
    > quite different than those in Unix or Linux. The group 'wheel'
    > in the *BSDs is just another name for 'root' as there is NO 'root'
    > group. The real difference is that a user has to be in the 'wheel'
    > group to be able to 'su' to root. It's supposed to be more secure
    > that way.
    >
    > However I have had some design problems with the way it is
    > implemented, as there are holes in the concept from my POV.
    > It's basically nothing more than a two-password way of getting
    > root privledges - but when I've questioned it no one I've received
    > no good reasons why it isn't more secure.
    >
    > At it is installed 'wheel' is just the name of
    > the group that 'root' is in, and there are no other users
    > in 'wheel' except group when you install it. If you change the
    > name of group 0 in /etc/groups to wheel it will look the same as
    > in *BSD. And if you remove group 0, any user can su to root.
    >
    > >--RLR

    >
    > Bill
    > --
    > Bill Vermillion - bv @ wjv . com


    FWIW the PAM module pam_wheel.so controls su privileges and the
    "wheel" group. Linux distros vary on the default configuration. In
    the Oracle (!) Red Hat Enterprise clone I'm looking at just now it's
    commented out of /etc/pam.d/su so "wheel" is just another group on
    this system.

    --RLR


+ Reply to Thread