Bug#484841: staff group root equivalence

[Thijs Kinkhorst-4]

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 violates the principle of least surprise. This is not the
first and probably not the last time someone accidentally discovers that the
staff group has root-equivalent semantics. This is not obvious, and there's
scarce documentation about the fact that this group implies root and is hence
very different from many other groups on the system. Such a property should
not come as a surprise.

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 this difference, or there are
other needs than writing /usr/local specifically. I have no evidence that
this feature is in common enough use that would support it being the default.

There are the problems with the approach which have been cited earlier in this
bug and those linked from it, especially #299007 has some discussion and has
support of a number of DD's for changing this. 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).


thanks,
Thijs

[Russ Allbery-2]

Thijs Kinkhorst <thijs@...> 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 this difference, or
> there are other needs than writing /usr/local specifically. I have no
> evidence that this feature is in common enough use that would support it
> being the default.

I'm generally inclined to agree with this.  However:

> There are the problems with the approach which have been cited earlier
> in this bug and those linked from it, especially #299007 has some
> discussion and has support of a number of DD's for changing this. 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.  Packages create
additional directories in /usr/local in their maintainer scripts, and
currently Policy says that they need to maintain these permissions and
ownership.  In the absence of that sort of package support, one will end
up with files and directories with the wrong ownership and have to
periodically fix that by hand.  It's therefore not *quite* trivial.

That being said, it's not clear to me that all the packages that in theory
should be setting this ownership and permissions actually do so.
debhelper's dh_usrlocal will do the right thing, but I don't think all of
the packages involved use it, and I don't think enough people use this
feature to check and file bugs against packages that don't do the
equivalent.  (Which is another argument for dropping the feature.)

Certainly among the sysadmins I talk to on a regular basis, sudo has
completely supplanted these sorts of group schemes.  I think the last time
I used a staff group system for something like this was in about 1997.

--
Russ Allbery (rra@...)               <http://www.eyrie.org/~eagle/>



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Thijs Kinkhorst-4]

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.  Packages create
> additional directories in /usr/local in their maintainer scripts, and
> currently Policy says that they need to maintain these permissions and
> ownership.  In the absence of that sort of package support, one will end
> up with files and directories with the wrong ownership and have to
> periodically fix that by hand.  It's therefore not *quite* trivial.

You're right that the exact triviality of this is debatable. However I think
we can agree that in any case it's very well possible to ensure those
permissions the admin requires are present without much hassle, be it a
simple puppet/cfengine recipe, a dpkg post-invoke command, etc..


Thijs

[Don Armstrong]

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 staff group (?).

2) Make /usr/local and subdirectories root:root 0755 by default
instead. (Probably also do #1)

3) Make subdirectories of /usr/local are 2775 root:staff if /usr/local
is that way by default, otherwise they are 0755. New installs have
/usr/local root:root 0755. Suggest switching /usr/local to root:root
0755 once if there is no-one in the staff group on upgrades.

I'm personally leaning towards doing #2 and #1 too, but if there is
still a sufficient use case for having /usr/local root:staff, then
maybe #3 and #1 is a better option.

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 historically.]


Don Armstrong

--
We must realize that today's Establishment is the New George III.
Whether it will continue to adhere to his tactics, we do not know. If
it does, the redress, honored in tradition, is also revolution.
 -- William O. Douglas _Points of Rebellion_

http://www.donarmstrong.com              http://rzlab.ucr.edu



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Bdale Garbee]

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 historically.]

I can't think of such a case.  

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.

Bdale




--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Manoj Srivastava]

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 university employees and IT were supposed to
 be in charge of the machines, and responsible for backups and other
 major maintenance, research group faculty and graduate students  ran
 the machines (often paid for by grants in the first place).

        So, the grad students and faculty were added to staff locally,
 but did not have root access; (NIS was in use) they could isntall
 things in /usr/local, and /usr/local came first in the PATH.

        This way, each research group had special privileges to their
 machines, but not any others,  and the IT folks still had control.

        Similar things were done at some of the larger  companies I
 worked for; so there is a use case. (And I think UNIX machines back in
 the 80's and early 90's came set up that way by default; I know Ultrix
 and OSF/1 did).

        Whether you find that use case a compelling option for the
 default is another thing.

        manoj
--
Even a hawk is an eagle among crows.
Manoj Srivastava <srivasta@...> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Don Armstrong]

On Mon, 02 Mar 2009, Manoj Srivastava wrote:
> This way, each research group had special privileges to their
> machines, but not any others, and the IT folks still had control.
>
> Similar things were done at some of the larger companies I worked
> for; so there is a use case. (And I think UNIX machines back in the
> 80's and early 90's came set up that way by default; I know Ultrix
> and OSF/1 did).

It seems to me that most of these cases would be dealt with using sudo
now, as it would enable you to restrict the users to having root
access on a specific machine, since being in staff means being able to
trivially get root on that machine at any time. [And sudo at least has
methods of controling and/or accounting the access.]
 

Don Armstrong

--
"You have many years to live--do things you will be proud to remember
when you are old."
 -- Shinka proverb. (John Brunner _Stand On Zanzibar_ p413)

http://www.donarmstrong.com              http://rzlab.ucr.edu


--
To UNSUBSCRIBE, email to debian-ctte-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Manoj Srivastava]

On Mon, Mar 02 2009, Don Armstrong wrote:

> On Mon, 02 Mar 2009, Manoj Srivastava wrote:
>> This way, each research group had special privileges to their
>> machines, but not any others, and the IT folks still had control.
>>
>> Similar things were done at some of the larger companies I worked
>> for; so there is a use case. (And I think UNIX machines back in the
>> 80's and early 90's came set up that way by default; I know Ultrix
>> and OSF/1 did).
>
> It seems to me that most of these cases would be dealt with using sudo
> now, as it would enable you to restrict the users to having root
> access on a specific machine, since being in staff means being able to
> trivially get roo

        Not quite. You see, us grad students in the staff group were
 _not_ supposed to be root, or be bale to modify the vendor directories
 (who knows, it might have violated the universities support contract).

        We were just give access to /usr/local, and /etc/ (not /usr or
 the like). The permissions were limited, and the group ACL was used to
 modulate _where_ in the file system one had god-like access.

        Unless my sudo-fu is entirely lacking, sudo access is command
 based, not path based.

        Not that it makes much of a difference in Debian selecting a
 default, really.  But I can see a use case in a large environment with
 subgroups where limited privileges are required -- and the /usr/local
 hierarchy, with the support for local overrides in path, programs like
 perl and emacs, made such setups easy for overlaying such privileges on
 a subset of the machines.

        manoj
--
Tact is the art of making a point without making an enemy.
Manoj Srivastava <srivasta@...> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-ctte-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Don Armstrong]

On Mon, 02 Mar 2009, Manoj Srivastava wrote:
> You see, us grad students in the staff group were _not_ supposed to
> be root, or be bale to modify the vendor directories (who knows, it
> might have violated the universities support contract).

Yeah, but by default, if you have staff access, you can easily gain
root access, so there's really no distinction between the two. [In
Debian, this could be done by shoving in a special /usr/local/bin/awk
to trap cron.daily/standard calling it as root, for example.]

> Not that it makes much of a difference in Debian selecting a
> default, really. But I can see a use case in a large environment
> with subgroups where limited privileges are required -- and the
> /usr/local hierarchy, with the support for local overrides in path,
> programs like perl and emacs, made such setups easy for overlaying
> such privileges on a subset of the machines.

The real problem is that by default root's PATH contains
/usr/local/sbin and /usr/local/bin, so you have to jump through quite
a few extra hoops to make the distinction between root and staff
viable in the first place.


Don Armstrong

--
"People selling drug paraphernalia ... are as much a part of drug
trafficking as silencers are a part of criminal homicide."
 -- John Brown, DEA Chief

http://www.donarmstrong.com              http://rzlab.ucr.edu


--
To UNSUBSCRIBE, email to debian-ctte-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Ian Jackson]

Don Armstrong writes ("Re: Bug#484841: staff group root equivalence"):
> Yeah, but by default, if you have staff access, you can easily gain
> root access, so there's really no distinction between the two. [In
> Debian, this could be done by shoving in a special /usr/local/bin/awk
> to trap cron.daily/standard calling it as root, for example.]

Since I perpetrated this I should explain it.

It is useful to have a group which is able to write to /usr/local.
This allows people who have _in principle_ root access to avoid
accidents.

A user who is in group staff can avoid becoming root to edit things in
/usr/local, thus limiting the damage they can do by mistake.  One big
example for this is `make install'.  If there is some set of process
properties which have write access to /usr/local but not to /, then
`make install' is much safer - it can't accidentally drop stuff all
over the rest of the filesystem.  Of course you're still exposed to
malice, but `sudo make install' is not really advisable even if you
know the source tree not to be malicious - after all it might be buggy
or the author might have different ideas where to put things.

On my own systems I typically run much of the time using an account
which has passwordless access to root, just by saying `really' (really
is a bit like sudo only simpler and less broken).  I put myself in the
staff group and that means I can mess about in /usr/local without
having to specially don a root hat (eg, `really emacs').  This helps
avoid accidents.

(Note that even with passworded sudo, subversion of an account which
can `sudo bash' can become equivalent to root the next time the real
human types the password.)


Obviously the best answer to how to provide some set of processes
(including all the processes of certain users) with the ability to
write to /usr/local is to make /usr/local owned by some group and mode
g+rw (directories g+rwsx).

Perhaps the choice of the name `staff' for this group was a mistake.
It's a cultural convention that I had picked up on a couple of UNIX
systems I had acquired over the preceding years, but of course other
people may have different conventions.  So I don't object to the idea
that the group should be renamed.

Also since an administrator who wants this setup can easily institute
it by hand, with a group of their choice, I don't mind if the default
install is changed.  BUT:

What _is_ important is that the existing installations aren't broken,
for example by new packages creating directories with the wrong
permissions.  With the current arrangements this is difficult to do
with a different group name: packages are expected to contain
directories which are group-owned by `staff', so there is not really
much facility for local configuration.

So I would suggest that documenting the situation would probably be
best.  After all anyone who puts users in a system group ought to have
some care about what they're granting access to.

If change is felt to be essential then I think the only option is to
require packages to create directories in /usr/local with
`mkdir -p -m2755' (or something like it).  If we do that then those
directories will naturally inherit the permissions from their parents,
so that the local configuration will be sticky.

Ian.


--
To UNSUBSCRIBE, email to debian-ctte-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Don Armstrong]

On Wed, 11 Mar 2009, Ian Jackson wrote:
> A user who is in group staff can avoid becoming root to edit things
> in /usr/local, thus limiting the damage they can do by mistake. One
> big example for this is `make install'.

It's probably not advisable to run 'make install' as any privileged
(or potentially privileged) user at all.

> Obviously the best answer to how to provide some set of processes
> (including all the processes of certain users) with the ability to
> write to /usr/local is to make /usr/local owned by some group and
> mode g+rw (directories g+rwsx).
>
> Perhaps the choice of the name `staff' for this group was a mistake.

If we can make the default group name slightly more self-documenting,
that'd be ideal. Something like 'localroot' or similar would clue
people in that the group isn't something that you'd randomly stick
people in.

> What _is_ important is that the existing installations aren't
> broken

Right. No matter what we choose to do, we need to make sure that
existing installs which knowingly utilize root:staff can continue to
do so. [It may be reasonable to warn once after adopting a new
convention if someone has users in a group that is g+w on directories
in root's default path, but we can probably leave that up to the
base-passwd maintainers to decide.]
 
> So I would suggest that documenting the situation would probably be
> best. After all anyone who puts users in a system group ought to
> have some care about what they're granting access to.

I think we're all in agreement now that at least documenting is
required.
 
> If change is felt to be essential then I think the only option is to
> require packages to create directories in /usr/local with `mkdir -p
> -m2755' (or something like it). If we do that then those directories
> will naturally inherit the permissions from their parents, so that
> the local configuration will be sticky.

I think something along these lines may be ideal (2775?). [The exact
mechanism of implementing this isn't that important to me.]


Don Armstrong

--
a friend will help you move
a best friend will help you move bodies
but if you have to move your best friend's body
you're on your own
 -- a softer world #242
    http://www.asofterworld.com/index.php?id=242

http://www.donarmstrong.com              http://rzlab.ucr.edu


--
To UNSUBSCRIBE, email to debian-ctte-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Andreas Barth]

* Don Armstrong (don@...) [090302 22:16]:

> On Mon, 02 Mar 2009, Manoj Srivastava wrote:
> > This way, each research group had special privileges to their
> > machines, but not any others, and the IT folks still had control.
> >
> > Similar things were done at some of the larger companies I worked
> > for; so there is a use case. (And I think UNIX machines back in the
> > 80's and early 90's came set up that way by default; I know Ultrix
> > and OSF/1 did).
>
> It seems to me that most of these cases would be dealt with using sudo
> now, as it would enable you to restrict the users to having root
> access on a specific machine, since being in staff means being able to
> trivially get root on that machine at any time.

I would like to get on with this bug report.


To me, the situation looks as follows: Having write-access for group
staff to /usr/local was a resonable decision when it was decided
first. However, since then time went by, and it looks like most
reasonable use cases disappeared. I agree with the principle of least
surprise, and so I think we should change that behaviour.

Ian said that we should require packages to create directories in
/usr/local with mode 2755, so that permissions will be inherited.
I agree that we should try to make it possible for users to keep a
special group.

However, I'm not sure if that's the best way to achieve it - I didn't
try out but I'd assume that any directory in a deb won't get the group
inherited from the parent directory. I think that a Post-Invoke-action
in apt.conf would be the better way. (We should probably document that
somewhere how to achive it.)


Anyways, I think we should do the basic decision whether we want to
/usr/local to be writeable by staff or not soon, and then try how to
best do a transition.


cheers,
Andi


--
To UNSUBSCRIBE, email to debian-ctte-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Russ Allbery-2]

Andreas Barth <aba@...> writes:

> However, I'm not sure if that's the best way to achieve it - I didn't
> try out but I'd assume that any directory in a deb won't get the group
> inherited from the parent directory. I think that a Post-Invoke-action
> in apt.conf would be the better way. (We should probably document that
> somewhere how to achive it.)

Policy requires that you not ship directories in /usr/local in the deb.

    However, the package may create empty directories below /usr/local
    so that the system administrator knows where to place site-specific
    files. These are not directories in /usr/local, but are children of
    directories in /usr/local. These directories (/usr/local/*/dir/)
    should be removed on package removal if they are empty.

    Note, that this applies only to directories below /usr/local, not in
    /usr/local. Packages must not create sub-directories in the
    directory /usr/local itself, except those listed in FHS, section
    4.5. However, you may create directories below them as you wish. You
    must not remove any of the directories listed in 4.5, even if you
    created them.

    Since /usr/local can be mounted read-only from a remote server,
    these directories must be created and removed by the postinst and
    prerm maintainer scripts and not be included in the .deb
    archive. These scripts must not fail if either of these operations
    fail.

so I think requiring maintainer script changes is the best way to do
this.  I don't think using apt.conf options to clean up after maintainer
script changes will work well.

> Anyways, I think we should do the basic decision whether we want to
> /usr/local to be writeable by staff or not soon, and then try how to
> best do a transition.

I would prefer to drop the writeability of /usr/local by staff
personally.  I don't think it serves much useful purpose these days
given the existence of tools like sudo, and where it does, I think we
can work out a transition plan that will make it relatively easy for
sites to recreate the concept.

--
Russ Allbery (rra@...)               <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-ctte-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Andreas Barth]

* Russ Allbery (rra@...) [090706 23:55]:

> Andreas Barth <aba@...> writes:
> > Anyways, I think we should do the basic decision whether we want to
> > /usr/local to be writeable by staff or not soon, and then try how to
> > best do a transition.
>
> I would prefer to drop the writeability of /usr/local by staff
> personally.  I don't think it serves much useful purpose these days
> given the existence of tools like sudo, and where it does, I think we
> can work out a transition plan that will make it relatively easy for
> sites to recreate the concept.

I agree.

I think we shouldn't decide about the details of the transition plan,
but just about the plain fact.


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 only be implemented after an
appropriate transition plan exists, so that system administrators can
keep that functionality. (Reasons for the change are the adaption of
other tools like sudo on most sites, and the concept of "least
surprise" for novice users.)

3. Further discussion.


Comments?



Cheers,
Andi


--
To UNSUBSCRIBE, email to debian-ctte-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Russ Allbery-2]

Andreas Barth <aba@...> writes:

> 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 only be implemented after an
> appropriate transition plan exists, so that system administrators can
> keep that functionality. (Reasons for the change are the adaption of
> other tools like sudo on most sites, and the concept of "least
> surprise" for novice users.)
>
> 3. Further discussion.

Sounds good to me.

--
Russ Allbery (rra@...)               <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-ctte-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Don Armstrong]

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 only be implemented after an
> appropriate transition plan exists, so that system administrators can
> keep that functionality.

Suggest "This change should only be implemented after an appropriate
transition plan exists which enables system administrators to maintain
the ability of group staff to write to /usr/local." instead (which is
what I think you mean.)

> (Reasons for the change are the adaption of other tools like sudo on
> most sites, and the concept of "least surprise" for novice users.)
>
> 3. Further discussion.

This seems reasonable to me too.
 

Don Armstrong

--
This can't be happening to me. I've got tenure.
 -- James Hynes _Publish and Perish_

http://www.donarmstrong.com              http://rzlab.ucr.edu



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Bdale Garbee]

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 /usr/local is not writeable by
> > group staff anymore. This change should only be implemented after an
> > appropriate transition plan exists, so that system administrators can
> > keep that functionality.
>
> Suggest "This change should only be implemented after an appropriate
> transition plan exists which enables system administrators to maintain
> the ability of group staff to write to /usr/local." instead (which is
> what I think you mean.)

Good change.

> > (Reasons for the change are the adaption of other tools like sudo on
> > most sites, and the concept of "least surprise" for novice users.)
> >
> > 3. Further discussion.
>
> This seems reasonable to me too.

I agree.

Bdale





--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Andreas Barth]

* Don Armstrong (don@...) [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 not writeable by
> > group staff anymore. This change should only be implemented after an
> > appropriate transition plan exists, so that system administrators can
> > keep that functionality.
>
> Suggest "This change should only be implemented after an appropriate
> transition plan exists which enables system administrators to maintain
> the ability of group staff to write to /usr/local." instead (which is
> what I think you mean.)

yes.


Cheers,
Andi



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Steve Langasek]

On Sun, Jul 12, 2009 at 03:50:39PM +0200, 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 only be implemented after an
> appropriate transition plan exists, so that system administrators can
> keep that functionality. (Reasons for the change are the adaption of
> other tools like sudo on most sites, and the concept of "least
> surprise" for novice users.)

> 3. Further discussion.

> Comments?

Looks like we've covered the options (with the proposed amendments), and I'm
content to vote on this.  I'll definitely vote 3) last, because I'm largely
of the view that this is bikeshedding, and either solution meets the needs
of the vast majority of users.

--
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@...                                     vorlon@...


--
To UNSUBSCRIBE, email to debian-ctte-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Bdale Garbee]

On Thu, 2009-07-23 at 13:25 +0200, Steve Langasek wrote:

> On Sun, Jul 12, 2009 at 03:50:39PM +0200, 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 only be implemented after an
> > appropriate transition plan exists, so that system administrators can
> > keep that functionality. (Reasons for the change are the adaption of
> > other tools like sudo on most sites, and the concept of "least
> > surprise" for novice users.)
>
> > 3. Further discussion.
>
> > Comments?
>
> Looks like we've covered the options (with the proposed amendments), and I'm
> content to vote on this.  I'll definitely vote 3) last, because I'm largely
> of the view that this is bikeshedding, and either solution meets the needs
> of the vast majority of users.

I agree.

Bdale



--
To UNSUBSCRIBE, email to debian-ctte-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...