Comment 43 for bug 13795

Message-ID: <email address hidden>
Date: Sat, 19 Mar 2005 18:56:37 +1100
From: Brendan O'Dea <email address hidden>
To: Santiago Vila <email address hidden>, <email address hidden>
Subject: Re: Bug#299007: base-files: Insecure PATH

On Wed, Mar 16, 2005 at 06:00:14PM +0100, Santiago Vila wrote:
>On Wed, 16 Mar 2005, Brendan O'Dea wrote:
>> Having /usr/local staff writable is *very* useful when using CPAN to
>> install local packages w/- having to do the "make install" as root.
>>
>> This is a benefit I'd prefer not to see removed, since the alternative
>> generally involves giving sudo access to a subset of users... which is
>> in my experience tantamount to simply adding more entry points to
>> gaining uid=0*, worse IMHO than having a subset of the filesystem
>> writable to that same set of users.
>
>That's not really the alternative. The alternative is doing it yourself
>(i.e. chgrp -R staff /usr/local and so on) instead of it being the default.
>
>This proposal is not to prevent people from having /usr/local group-writable
>by staff, it's just a proposal to have "neutral permissions" in /usr/local.

Fair point, although while /usr/local is staff-writable by default, no
users are in group staff by default. So out of the box, this situation
is no different to having the group as root.

The only difference is to users who *do* wish to take advantage of this
facility, saving the need for:

  # chgrp -R staff /usr/local /var/local
  # chmod -R +t,g+w /usr/local /var/local

and requiring only the final step of:

  # adduser fred staff

>Should we count your mail as a formal objection? You know, it only
>takes a negative vote to reject a policy proposal, even if it's
>supported by a lot of people. I think this is going to be a real pity.

A formal objection? I was of the belief that this was still being
discussed.

While there has been some support, there is not consensus: both myself
and Bill Allombert have raised issues with the proposal as given in
message <email address hidden> of changing
the group of /usr/local to root.

I believe that the facility of having a group which may write to
/usr/local is very useful and should be retained. Furthermore, I would
assert that the current situation poses no security risks without the
administrator choosing to add users to the staff group.

The group need not be called "staff" specifically, since due to the
generic nature of the name it is possible that an administrator may
choose to add staff users to that group (either for documentary
purposes, or to provide write permission to some other, site-specific
part of the hierarchy) without being aware that this would allow them to
write to elements of root's PATH.

Using "local" for /usr/local (in line with the current "src" for
/usr/src) may be an option if the above was deemed to be a sufficient
risk.

Clearly documenting the possible risks of adding a user to the group
should probably be added to users-and-groups.txt .

Having /home writable by group staff OTOH doesn't seem particularly
useful.

--bod