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
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
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
* 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
|
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 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 anymore. This change should only
* 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 /usr/local is
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 should
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 that
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
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
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
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
Thijs Kinkhorst th...@debian.org 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
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.
15 matches
Mail list logo
