"Greg A. Woods" wrote:
> 
> I wouldn't put much stock in that document as a "Standard" if I were
> you.  :-)
> 
It is standard in the same way that IETF (where I once was active) 
produces standards -- voluntarily.  It appears to have nearly a decade 
of tweaking.  I've been aware of it for many years, and am unaware of a 
comparable document produced by another organization.  


> On the other hand it does give this very good piece of general advice
> (though unfortunately only in a footnote):
> 
>    [16] Deciding what things go into "sbin" directories is simple:  if a
>    normal (not a system administrator) user will ever run it directly,
>    then it must be placed in one of the "bin" directories.  Ordinary
>    users should not have to place any of the sbin directories in their
>    path.
> 
Often the footnotes are excellent!  I'll just note in passing that you 
elided the text in this same footnote, saying:

  For example, files such as chfn which users only occasionally use must 
  still be placed in /usr/bin. ping, although it is absolutely necessary 
  for root (network recovery and diagnosis) is often used by users and 
  must live in /bin for that reason.

  We recommend that users have read and execute permission for everything 
  in /sbin except, perhaps, certain setuid and setgid programs. The 
  division between /bin and /sbin was not created for security reasons or 
  to prevent users from seeing the operating system, but to provide a good 
  partition between binaries that everyone uses and ones that are 
  primarily used for administration tasks. There is no inherent security 
  advantage in making /sbin off-limits for users.


> Note 
>... 
[various GNU bashing comments elided]


> > Of these, chgrp is in /rescue, and required for /bin by FHS.
> 
> If "chgrp" is required in /bin by this so-called "FHS" then that
> document flawed and not really compatible with POSIX-1003.1-2001 since
> the latter requires that all the "chgrp" functionality be also available
> through "chown".  This is especially true in single user mode where the
> user is the superuser and thus the potential restrictions of "chown" do
> not apply.
> 
I find nothing to support your statements in the online version of 
POSIX-1003.1-2001, at 
  http://www.opengroup.org/onlinepubs/007904975/toc.htm


> As I understand it "chgrp" is only kept separately defined and has not
> been deprecated in POSIX-1003.1 so that it can be put in a directory
> that is by default in the user's path while "chown" can be put off out
> of harm's way in a "system" directory (/sbin or /usr/sbin) on those
> systems where non-privileged users are not allowed to change user
> ownership but rather only group ownership.
> 
I find nothing to support your statements in the online version of 
POSIX-1003.1-2001. 

Indeed, that document explicitly notes at:
  http://www.opengroup.org/onlinepubs/007904975/utilities/chgrp.html
  "The functionality of chgrp is described substantially through 
  references to chown(). In this way, there is no duplication of effort 
  required for describing the interactions of permissions, multiple 
  groups, and so on."

Likewise:
  http://www.opengroup.org/onlinepubs/007904975/utilities/chown.html
  "The functionality of chown is described substantially through 
  references to functions in the System Interfaces volume of IEEE Std 
  1003.1-2001. In this way, there is no duplication of effort required 
  for describing the interactions of permissions, multiple groups, and 
  so on.

  "The 4.3 BSD method of specifying both owner and group was included in 
  this volume of IEEE Std 1003.1-2001 because:
    ..."

Implies that the BSD chown isn't implemented on all systems and it's a 
new feature (with a change in syntax). 

So, maybe chgrp will go away someday, but I don't see any indication 
of that in any standard document.
-- 
William Allen Simpson
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32