Hi, The TC has decided on the following resolution for the group staff issue:
> | 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 which enables system administrators
> | to maintain the ability of group staff to write to /usr/local.
> | (Reasons for the change are the adaption of other tools like sudo on
> | most sites, and the concept of "least surprise" for novice users.)
I'd like to move forward with this bug so that it can be resolved for squeeze.
The TC decided an "appropriate transition plan" should exist. If we would
change the default on a new system to root:root 2775 for /usr/local, a
sysadmin needs to chgrp that to staff once to regain the old behaviour.
A transition plan should hence entail:
a) Update documentation to reflect new default;
b) Mention in documentation how to enable the 'staff group' functionality if
so desired;
c) Update policy;
d) Update base-files.
I think these steps could happen in parallel.
Attached are patches to facilitate all steps above.
* debian-reference.patch removes mention of the staff group. This document is
intended as a general overview ("provide overview and skip corner cases",
mentions the preface), and the staff group is specific enough not to be a
necessary part of this. The securing-debian manual (see next bullet) is more
than appropriate for this.
* securing-debian.patch updates mention of the staff group in the Securing
Debian manual to explain that you need to chgrp /usr/local once to achieve
the desired functionality, and warn about the root equivalence. Remove
mention of /home in this context as we don't ship staff-writable home for a
long time now and that has no real identified use.
* debian-policy.patch updates policy to drop the requirement to make items
under /usr/local owned by the staff-group. Permissions 2775 remain as they
are harmless when used with root:root, but keep the property that once the
thing has been made group-staff, it will work as previously and will stick.
* base-files.patch implements the policy change.
I'm curious to learn if there's a desire for more transition planning than
this, and what it should entail. Otherwise I'll push forward with filing the
respective patches against their packages.
cheers,
Thijs
diff --git a/en/tutorial.en.xml b/en/tutorial.en.xml
index 64937e7..faab7a5 100644
--- a/en/tutorial.en.xml
+++ b/en/tutorial.en.xml
@@ -931,15 +931,6 @@ $ ls -l foo bar
<entry colsep="1" rowsep="1">
<para> System monitoring logs. </para>
</entry>
- </row><row rowsep="1">
- <entry colsep="1" rowsep="1">
- <para>
- <code>staff</code>
- </para>
- </entry>
- <entry colsep="1" rowsep="1">
- <para> Some directories for junior administrative work: "<code>/usr/local</code>", "<code>/home</code>". </para>
- </entry>
</row></tbody>
</tgroup>
</table>
Index: securing-howto/en/faq.sgml =================================================================== --- securing-howto/en/faq.sgml (revision 6829) +++ securing-howto/en/faq.sgml (working copy) @@ -494,9 +494,13 @@ access to a video device. <item>staff: Allows users to add local modifications to the system -(<file>/usr/local</file>, <file>/home</file>) without needing root -privileges. Compare with group "adm", which is more related to -monitoring/security. +(under <file>/usr/local</file>) without needing root +privileges. To enable this, change the group of <file>/usr/local</file> +to staff; subsequent updates will respect this. Be careful though when doing +this: because <file>/usr/local/bin</file> is in root's path, this group +becomes essentially root-equivalent! Tools like 'sudo' may provide a +solution to this problem aswell. +Compare with group "adm", which is more related to monitoring/security. <item>users: While Debian systems use the private user group system by default (each user has their own group), some prefer to use a more @@ -518,8 +522,11 @@ <p>The 'adm' group are usually administrators, and this group permission allows them to read log files without having to <prgn>su</prgn>. The 'staff' group are usually help-desk/junior -sysadmins, allowing them to work in <file>/usr/local</file> and create -directories in <file>/home</file>. +sysadmins, allowing them to work in <file>/usr/local</file>, +if the group of this directory has been changed to 'staff' once. +Note that doing this makes the members of the 'staff' group +essentially root, since <file>/usr/local/bin</file> is in +root's path. <sect1>Why is there a new group when I add a new user? (or Why does Debian give each user one group?)
diff --git a/policy.sgml b/policy.sgml
index deae2dd..f6d1aac 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -5674,7 +5674,6 @@ if [ ! -e /usr/local/share/emacs ]
then
if mkdir /usr/local/share/emacs 2>/dev/null
then
- chown root:staff /usr/local/share/emacs
chmod 2775 /usr/local/share/emacs
fi
fi
@@ -5708,7 +5707,7 @@ rmdir /usr/local/share/emacs 2>/dev/null || true
The <file>/usr/local</file> directory itself and all the
subdirectories created by the package should (by default) have
permissions 2775 (group-writable and set-group-id) and be
- owned by <tt>root:staff</tt>.
+ owned by <tt>root:root</tt>.
</p>
</sect1>
--- debian/postinst.in 2009-04-24 19:49:57.000000000 +0200
+++ debian/postinst.in 2009-08-11 22:18:56.000000000 +0200
@@ -5,7 +5,6 @@
if [ ! -d $1 ]; then
mkdir -p $1
fi
- chown root:staff $1 2> /dev/null || true
chmod 2775 $1 2> /dev/null || true
}
signature.asc
Description: This is a digitally signed message part.
