On Fri, 2009-07-24 at 18:55 +0200, Andreas Barth wrote:
> Hi,
>
> I'm calling on votes now for these three options (the last one isn't a
> proposal, but by default in the option set). According to the
> consitution, the voting periode last for up to one week, or until the
> outcome is no longer in
On Fri, Jul 24, 2009 at 06:55:01PM +0200, Andreas Barth wrote:
> I'm calling on votes now for these three options (the last one isn't a
> proposal, but by default in the option set). According to the
> consitution, the voting periode last for up to one week, or until the
> outcome is no longer in
Andreas Barth writes ("Call for votes (was: Bug#484841: staff group root
equivalence)"):
> | 1. Keep /usr/local writeable by group staff (i.e. leave things as they
> | are).
>
> | 2. Decide to change the default so that /usr/local is not writeable by
> | group staff an
On Fri, 24 Jul 2009, Andreas Barth wrote:
> I'm calling on votes now for these three options (the last one isn't a
> proposal, but by default in the option set). According to the
> consitution, the voting periode last for up to one week, or until the
> outcome is no longer in doubt.
>
> | 1. Keep
* Andreas Barth (a...@not.so.argh.org) [090724 18:55]:
> | 1. Keep /usr/local writeable by group staff (i.e. leave things as they
> | are).
>
> | 2. Decide to change the default so that /usr/local is not writeable by
> | group staff anymore. This change should only be implemented after an
> | app
Hi,
I'm calling on votes now for these three options (the last one isn't a
proposal, but by default in the option set). According to the
consitution, the voting periode last for up to one week, or until the
outcome is no longer in doubt.
| 1. Keep /usr/local writeable by group staff (i.e. leave t
* Don Armstrong (d...@debian.org) [090712 20:37]:
> On Sun, 12 Jul 2009, Andreas Barth wrote:
> > For this reason, I intend to propose the following options:
> >
> > 1. Keep /usr/local writeable by group staff (i.e. leave things as they
> > are).
> >
> > 2. Decide to change the default so that /u
On Sun, 2009-07-12 at 11:22 -0700, Don Armstrong wrote:
> On Sun, 12 Jul 2009, Andreas Barth wrote:
> > For this reason, I intend to propose the following options:
> >
> > 1. Keep /usr/local writeable by group staff (i.e. leave things as they
> > are).
> >
> > 2. Decide to change the default so t
On Sun, 12 Jul 2009, Andreas Barth wrote:
> For this reason, I intend to propose the following options:
>
> 1. Keep /usr/local writeable by group staff (i.e. leave things as they
> are).
>
> 2. Decide to change the default so that /usr/local is not writeable by
> group staff anymore. This change
Hi,
On Mon, Mar 02 2009, Bdale Garbee wrote:
>
> I, too, have never used group 'staff' but have assumed others did since
> I seem to recall some push-back on the idea of changing this in the
> past.
I have, but that was a long time ago. Back at UMASS, we had a
situation where while the u
On Mon, 2009-03-02 at 00:48 -0800, Don Armstrong wrote:
> Is there a use case for having people in the group staff with
> /usr/local g+w that isn't better solved using sudo to provide similar
> access? [I've never had people in the staff group, so I don't know
> what people were using it for histo
From what I can tell, we need to do at least one of the following:
1) Make it more obvious that adding people to the staff group is
rougly equivalent to giving them root access by fixing the description
of the group in base-passwd, and possibly having base-passwd warn if
there are users in the sta
Hi Russ,
Thanks for your quick response.
On moandei 2 Maart 2009, Russ Allbery wrote:
> > Should you need the functionality, it's of course trivial to recreate the
> > situation (you need to take some action anyway to make use of it).
> To be fair, it's not as clear to me that this is true. Pac
Thijs Kinkhorst writes:
> Meanwhile, this is just one way to implement differentiation between
> junior and senior sysadmins. There are many others, a notable one being
> the use of "sudo". The specifics of group staff may not fit your setup:
> perhaps another group from LDAP is used to decide on
Hi,
A recent report to the security team redrew my attention to this bug assigned
to the TC for a while now, about the staff group being root-equivalent. As
we're at the start of a release cycle, in my opinion now would be a good
moment to resolve it. My view on it follows.
Firstly, I think it
15 matches
Mail list logo
