Jakob Bohm <[EMAIL PROTECTED]> wrote: >> Is this feature seldom used, so we do not care much about it; or is >> it often used, and so possibly worth retaining? > > I certainly use it. I also create multiple ... 'almost root' accounts ...
You are smart enough to set up features similar to group staff, and do not need group staff to be available *by default*. > The real, fundamental, security issue is that most > implementations of the NFS protocol ... Group staff and NFS should not co-exist. Which one should Debian policy warn against? Debian policy does not force you to use NFS, it must not force you to have group staff either. > These broken-by-design NFS implementations ... trojanize all user > writable files ... all systems should be given the 'root compromise' > cleanup. Not quite as bad as that: root-squash should protect you somewhat. >> Is it documented anywhere that you should only give group staff >> privileges to those that also have the root password? > > I think it is probably documented somewhere (and certainly basic > os-independent sysadmin knowledge) ... Specific reference, please. Is it documented by Debian, in the policy that forces group staff upon you? >> At no time was I arguing for banning whatever ownership of /usr/local >> by policy; I only wanted to also allow it being owned by root. ... >> ... However, you must also grant me the right to run my machine >> securely, and should not try to prevent me from doing so by policy. > > NOT agreed. ... Do you really mean that? Which one do you mean: should policy specifically disallow root ownership of /usr/local, or should it prevent me from running my machine in a way that I (foolishly) think is safe? > The problem is that most NFS-servers and most versions of the > NFS protocol do not perform sufficient validation ... NFS may be ugly and insecure. Should we banish it from Debian? Cheers, Paul Szabo [EMAIL PROTECTED] http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of Sydney Australia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
