# [OmniOS-discuss] user_attr.d directory shipped, but not functional

Peter Tribble peter.tribble at gmail.com
Fri Aug 29 07:52:41 UTC 2014

- Previous message: [OmniOS-discuss] user_attr.d directory shipped, but not functional
- Next message: [OmniOS-discuss] user_attr.d directory shipped, but not functional
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    On Fri, Aug 29, 2014 at 7:55 AM, Lauri Tirkkonen <lotheac at iki.fi> wrote:

    > I don't know whether this is a distribution bug or exists in upstream
    > illumos so I'm reporting it here.
    >
    > I assumed since the base install, ie. pkg:/SUNWcs, ships
    > {auth,exec,prof,user}_attr.d directories and a file in them, that you
    > could drop a file in one of them and have it function similarly to
    > appending to the _attr file. This is, however, not the case for at least
    > user_attr:
    >

    The directories contains fragments that are used as part of self
    assembly to construct the resulting file (and it's the file such as
    /etc/user_attr that is actually used by the system).

    So, if you add additional files into these directories, you need to
    trigger self-assembly. Normally, packages delivering additional
    fragments to these .d directories will do so automatically, but
    otherwise you can force the update yourself:

    svcadm restart rbac

    > gutsman /etc # useradd foo
    > gutsman /etc # auths foo
    >
    > solaris.admin.wusb.read,solaris.device.cdrw,solaris.device.mount.removable,solaris.mail.mailq,solaris.profmgr.read
    > gutsman /etc # echo 'foo::::type=normal;auths=bar' > user_attr.d/foo
    > gutsman /etc # auths foo
    >
    > solaris.admin.wusb.read,solaris.device.cdrw,solaris.device.mount.removable,solaris.mail.mailq,solaris.profmgr.read
    > gutsman /etc # cat user_attr.d/foo >> user_attr
    > gutsman /etc # auths foo
    >
    > bar,solaris.admin.wusb.read,solaris.device.cdrw,solaris.device.mount.removable,solaris.mail.mailq,solaris.profmgr.read
    >
    > A quick look also didn't turn up any code that would handle these
    > directories (but I can be wrong). I think that these directories should
    > not be shipped at all -- it could lead to security problems in the worst
    > case (think shipping a setuid binary and a file in exec_attr.d to set
    > Forced Privilege on it; I actually did this in one of our packages but I
    > guess it's probably not limiting privileges at all).
    >
    > The .d directories are not referenced in any manual pages, though, but
    > it's still a bad idea to ship files which serve no purpose (as far as I
    > can tell :) and may confuse users.
    >
    > --
    > Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet
    > _______________________________________________
    > OmniOS-discuss mailing list
    > OmniOS-discuss at lists.omniti.com
    > http://lists.omniti.com/mailman/listinfo/omnios-discuss
    >

    --
    -Peter Tribble
    http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20140829/a8803b6e/attachment-0001.html>

- Previous message: [OmniOS-discuss] user_attr.d directory shipped, but not functional
- Next message: [OmniOS-discuss] user_attr.d directory shipped, but not functional
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

More information about the OmniOS-discuss mailing list