Very Computer

>Thanks
>Christophe BRIDET

> > > X-No-Archive: YES
> > > Christophe is describing an entirely different problem --
> > > when you put too many users into a single group the group
> > > entry gets rather large and then the system breaks because
> > > the line is too long.  The hashed password files (AIX doesn't
> > > have hashed group files -- perhaps you are thinking of
> > > Linux) can help if the /etc/passwd file is huge, but that's
> > > it.

> > > There is an APAR coming out Real Soon Now which deals
> > > with the problem of mkuser adding users to their primary
> > > group by default.  As always, I don't have the number, but if
> > > you pester me I might be able to dig it up.

> > Wow.  That problem's still around?  Why's it taken so long to fix
> > it and what are y'all gonna do to fix it?  It's been around since at
> > least the early days of 4.3.x.

> You have to understand that it isn't a "problem", it's one of those
> anomolous behaviours that people didn't consider 11 years ago when
> AIX v3 was being designed.  As such, it isn't really a "bug" -- the
> mkuser command was working exactly the way we wanted it to work
> and we had very good reasons.

> What happened is that system administrators, instead of creating
> groups to subdivide their users went off and put them all into one
> group (which is an administrative mistake -- it becomes the
> "everyone" group and that doesn't help with access control policies).

> Several releases back we changed mkuser due to customer requests
> to not add the user's name to /etc/group for their primary group.
> Well, some customer's complained about this change and it was
> changed back.

> When this issue again arose a decision was made to do something
> that would potentially make both sides happy -- add an option which
> allows the administrator to choose the behavior they want.

> SO .... the APAR, whose number is IY05836, adds a "configuration
> option" which lets the administrator decide -- add the user to their
> primary group in /etc/group or don't.  The upside is that you get
> whichever behavior =you= want.

> (Of course, there =is= a m*to this story -- we will (generally
> speaking) change things if we know what you want)

> --
> Julianne Frances Haugh                 "Life is either a daring adventure, or
> RS/6000 Security Development                 nothing at all."
> AIX Security Development                                -- Helen Keller
> http://www.veryComputer.com/

> X-No-Archive: YES

> > But if you allow a user to be added to the system and to a primary group
> and you do not
> > update /etc/group, haven't you lost one bit of validation that the user
> was really supposed
> > to be in that group?  For example, you walk away from your terminal as
> root, I edit /etc/passwd
> > and change my group id of 1(staff) to 0(system) and I and not listed in
> /etc/group.

> And if I instead write a shell script which changes both at
> once with a single command, haven't I defeated having
> the user in /etc/group as well as /etc/passwd?

> X-No-Archive: YES

> > > And if I instead write a shell script which changes both at
> > > once with a single command, haven't I defeated having
> > > the user in /etc/group as well as /etc/passwd?
> > ** that is true, but the more I get into security in unix, the more I think
> > it is an oxymoron and anything you can do that can cross reference something
> > else MIGHT give you a bit more security.  Maybe the only reason to get into
> > unix security is, the group hold their meetings in the BEST locations. <grin>

> You're starting to get into this whole fuzzy domain of "security
> by obscurity".  "If I can just make it a bit harder, maybe then ..."