Date: Mon, 15 Dec 2003 03:03:43 -0800 From: Eivind Eklund <eivind@FreeBSD.org> To: Brooks Davis <brooks@one-eyed-alien.net> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src UPDATING (initgroups) Message-ID: <20031215110343.GA97991@FreeBSD.org> In-Reply-To: <20031215005702.GB4077@Odin.AC.HMC.Edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Dec 14, 2003 at 04:57:02PM -0800, Brooks Davis wrote:
> I think we should put this in in stable and probably never remove it.
> I'd defintly object if we removed it before 4.11 because we need to ship
> at least one release with a warning before breaking things since I don't
> think this is a security issue. If someone can come up with a way not
> being a member of a group would be a security issue I'd withdraw that
> objection and just suggest that we add a special case syslog to stable
> to avoid confusion.
Groups can be used both as a positive and negative security control
mechanism. The logic for checking permissions is (pseudocode):
def get_flags(file, uid, groups)
if file.owner == uid
file.userflags
elsif groups.find { |group| group == file.group }
file.groupflags
else
file.otherflags
end
end
Note that you can limit particular a group by having more relaxed flags
for "other" than for the group.
Ie, if we have the following:
john in doe group
jane not in doe group
If we have a file
drwx---r-x 3 root doe 512 Sep 16 14:35 nondoes
then jane will have access to it, while john won't. If john lose the
doe group, he too will have access.
Note that this isn't an argument in either direction about how to handle
the change; I'm leaving that to you. The usage above isn't really
common, but it is a trick known to advanced admins.
Eivind.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031215110343.GA97991>