“mv */sbin/* */bin/”? (was: Proper shebang for python3)

[Thomas 'PointedEars' Lahn]

Eli the Bearded wrote:
^^^^^^^^^^^^^^^
Please post here using your real name.

> In comp.lang.python, Thomas 'PointedEars' Lahn <use...@PointedEars.de>
> wrote:

Attribution _line_, not attribution novel.

>> Michael Torrie wrote:
>>> On 7/24/19 4:20 PM, Cameron Simpson wrote:
>>>> That is some progress, hooray. Then there's just sbin -> bin to go.
>>> I suppose in the olden days sbin was for static binaries, […]
>> No, “sbin” is short for “*system* binaries” which in general only the
>> superuser should be able to execute.
>
> I think Michael is confusing "sbin" with the statically linked utilities
> some systems (particularly older ones, but also FreeBSD in /rescue/)
> have for repairing the system when things start to go bad. You'd want
> a shell (sh is great), a basic editor (eg, eg), and a smattering of
> other tools, akin to the ones listed as "must be in /sbin" in your
> linuxfoundation link.

ACK.

> But more than a few utilities in /sbin are useful for non-superusers.
> Eg ip or ifconfig for informational purposes like identifying current
> IP address and getting MAC.

ACK. But what appears useful for a non-superuser can be viewed as
compromising system security, or opening ways to make that easier,
by superusers/system administrators.

Keep in mind that originally, and in fact still due to servers on the
Internet, the majority of Unices have not been/are not only used by one
person each which is both a non-superuser and a superuser of the computer
system:

<https://en.wikipedia.org/wiki/Usage_share_of_operating_systems>

>> Which is why the above is a Very Bad Idea[tm].
>
> Why? Programs that can *only* be usefully run by a privileged user
> or in a system context (eg halt or getty) already *must* prevent non
> privileged use. So why would it be a Very Bad Idea[tm] to have them in
> a common directory like /bin/?

Because that a file should only or usually be executed by a superuser does
not imply that the owner of that file must be a superuser, or that it has
execute permission only for one superuser group or more, and vice-versa.

Also, it is easier to keep files that usually should only be executed by
a superuser in a separate directory, so that they are not immediately
available or listed to or for other users [e.g. in shell command resolution
(along PATH), in a directory listing, or in tab completion].

> (Feel free to crosspost and set follow-ups to another group if you like.
> But I would suggest *not* a Linux group, since this is something general
> to all Unix-likes.)

ACK. X-Post & F’up2 comp.unix.misc.

--
PointedEars

Twitter: @PointedEars2
Please do not cc me. /Bitte keine Kopien per E-Mail.

[Keith Thompson]

Thomas 'PointedEars' Lahn <Point...@web.de> writes:
> Eli the Bearded wrote:
> ^^^^^^^^^^^^^^^
> Please post here using your real name.
>
>> In comp.lang.python, Thomas 'PointedEars' Lahn <use...@PointedEars.de>
>> wrote:
>
> Attribution _line_, not attribution novel.

Please don't make up arbitrary nonexistent rules. Usenet has no real
name requirement, and there's nothing wrong with the attribution line
you're complaining about.

[...]

--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

[Thomas 'PointedEars' Lahn]

Keith Thompson wrote:

> Thomas 'PointedEars' Lahn <Point...@web.de> writes:
>> Eli the Bearded wrote:
>> ^^^^^^^^^^^^^^^
>> Please post here using your real name.
>>
>>> In comp.lang.python, Thomas 'PointedEars' Lahn <use...@PointedEars.de>
>>> wrote:
>>
>> Attribution _line_, not attribution novel.
>
> Please don't make up arbitrary nonexistent rules.

I did not; I made a request.

> Usenet has no real name requirement,

But I have; it is called courtesy, a concept that apparently you are not
very familiar with:

> and there's nothing wrong with the attribution line
> you're complaining about.

*You* have *shortened* the original attribution line without marking the
omission.

Also, your claim is wrong; see for example

<https://www.netmeister.org/news/learn2quote.html>

Finally, you should have directed your message to me via e-mail because it
is completely off topic. (Now that this cannot be helped anymore, my
counter-argument is posted here as well, of course.)

See e.g. <https://tools.ietf.org/html/rfc1855>

[Keith Thompson]

Thomas 'PointedEars' Lahn <Point...@web.de> writes:

[...]

> Finally, you should have directed your message to me via e-mail because it
> is completely off topic. (Now that this cannot be helped anymore, my
> counter-argument is posted here as well, of course.)

[...]

Good point. I'll reply by email.

[Eli the Bearded]

In comp.unix.misc, Thomas 'PointedEars' Lahn <use...@PointedEars.de> wrote:
> Eli the Bearded wrote:
> ^^^^^^^^^^^^^^^
> Please post here using your real name.

That is my nom-de-net for better than two decades.

> > In comp.lang.python, Thomas 'PointedEars' Lahn <use...@PointedEars.de>
> > wrote:
> Attribution _line_, not attribution novel.

Says the guy who just (a) took this topic to a different group as I
suggested and (b) feels it necessary to have two separate "face" headers
with images in excess of a 1000 bytes. I use that attribution line
*because* things get crossposted and to make it clear the the context
I'm replying from.

[this discussion is sparked by the request:

>>>> On 7/24/19 4:20 PM, Cameron Simpson wrote:
>>>>> That is some progress, hooray. Then there's just sbin -> bin to go.

> ACK. But what appears useful for a non-superuser can be viewed as
> compromising system security, or opening ways to make that easier,
> by superusers/system administrators.

If it can "compromis[e] system security" it needs to check permissions
anyway. There is nothing stopping me using a non-privleged account from
trying to run anything in /sbin anyway.

> Keep in mind that originally, and in fact still due to servers on the
> Internet, the majority of Unices have not been/are not only used by one
> person each which is both a non-superuser and a superuser of the computer
> system:

Hey, guess what? I've been a shell customer of Panix for over two
decades and Panix fits some 1500+ subscribers (these days) on four
(these days) multiuser shell boxes. "who|wc" gives me 43 users at the
moment on this box. I know all about Unix as a multiuser system.

>>> Which is why the above is a Very Bad Idea[tm].

>> So why would it be a Very Bad Idea[tm] to have them in a common directory
>> like /bin/?
> Because that a file should only or usually be executed by a superuser does
> not imply that the owner of that file must be a superuser, or that it has
> execute permission only for one superuser group or more, and vice-versa.

I don't see how that is relevant to my question.

> Also, it is easier to keep files that usually should only be executed by
> a superuser in a separate directory, so that they are not immediately
> available or listed to or for other users [e.g. in shell command resolution
> (along PATH), in a directory listing, or in tab completion].

Easier? It's a Very Bad Idea[tm] because people find it easier or may
get confused? Even a system with just busybox installed will have
commands that I have never run or expect to run on my own systems or the
systems I get paid to tend (eg tftp). And fewer results for tab
completion is probably a lost cause. On my personal linux box, which I
don't consider to have a lot of stuff:

$ ls /usr/bin |wc
2410 2410 24453
$ ls /sbin |wc
188 188 1807

The panix NetBSD is much tighter:

$ ls /sbin |wc
148 148 1371
$ ls /usr/bin |wc
499 499 3425

Well, tighter if you don't count /usr/local/bin/ ...

$ ls /usr/local/bin |wc
6480 6480 82052

Which is the first directory on the standard system PATH.

> ACK. X-Post & F’up2 comp.unix.misc.

It's not necessary to use high-bit characters in your text, either.

Elijah
------
does not find "smart" quotes to be an improvement in any way