On Mon, 2003-06-09 at 06:59, William Allen Simpson wrote:
> > 
> 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.

Hm.  I'll go on record as saying that I do not agree with this
statement by a standard, either voluntary or otherwise.

For what it's worth, it seems to me that the /sbin is not put there
to avoid use by users, only to avoid use by users who don't know
enough to change their $PATH accordingly; if you don't know how to
change $PATH to include /{,usr/}sbin, you probably shouldn't be
running much out of there anyway.  Sorry if that seems elitist, but
there's something about catering to power users who don't want
to learn that strikes me as sub-optimal.

So there it is.

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

It's not really off-limits, though.  It's just initially keeping
the knives out of the hands of the less-than-dextrous.

> 
> > 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 see nothing that says chown require chgrp functionality, but I'll
say I'm glad it has it.

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

No, but in practice, it's a good idea.

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

by 2001 it hadn't been implemented on all systems?  Wow, which ones
would they be?  All the major ones (*BSD, of course, and Loonix^WLinux,
and Sloaris, and HP-UX and AIX and, last I knew, Irix) support it.

AT&T even had it in svr4.

> 
> So, maybe chgrp will go away someday, but I don't see any indication 
> of that in any standard document.

I somehow doubt it, at least at the command level.

However, it seems to me that ch{own,grp,mod} should have been replaced
a LONG time ago with a command which was actually capable of doing
all *three* actions in one pass, say, "chogm" or something equally
horrific, with links to chown, chgrp and chmod performing the
appropriate action.

				--*greywolf;
--
NetBSD:  It's not just for breakfast anymore.