Boruch Baum <boruch_baum@???> writes:
> On 04/07/2016 01:05 PM, Rainer Weikusat wrote:
>> "Jack L. Frost" <fbt@???> writes:
>>> On Sun, Apr 03, 2016 at 08:17:32PM -0400, Boruch Baum wrote:
>>>> Please consider setting the default /etc/fstab to include:
>>>>

>>>> proc            /proc           proc    defaults,hidepid=2

>>>>
>>>> This has the effect of keeping the specific activities, process
>>>> ids, command lines and parameters of a user from other users.
>>>
>>> I've been using hidepid=2 as a default in my toy distro and haven't
>>> found a usecase where that would be a bad default. So unless there
>>> are common enough usecases where users need to see others'
>>> processes, I agree.
>>
>> Since this is an argument for changing the default behaviour, there
>> ought to be some "common enough" use cases where that would be
>> beneficial. Eg, why should daemon processes running on a machine used
>> by a single person, say, the proverbial "clueless newbie", be
>> forcibly hidden from the owner of the computer unless he happens to
>> be running as root?
> Nothing in Linux is done by 'force', Ranier. The sysadmin always has
> choice. The issue is whether basic security issues should be opt-in or
> opt-out.

That you keep asserting that this would be 'a basic security issue'
without ever substantiating it doesn't make it so.

> If the sysadmin of your example is so much a "clueless newbie",
> to not know how to use root (or even sudo), then no admin task
> whatsoever will be possible on the system.

In particular, when you then next suggest that any problem created by
this change can easily be solved by "well, just always run as root".

>> The 'common use case' where the default behaviour is useful would
>> still be a system with one physical user running processes supposed
>> to be various useful tasks using a variety of different user IDs. Eg,
>> the web server I'm using to get files onto iOS devices runs as
>> www-data, the DNS resolver as bind, the program getting my e-mails as
>> fetchmail, the timekeeping daemon as ntp, the line printer daemon as
>> daemon and all kernel threads runs as root. In case something "seems
>> wrong", eg, the system starts to behave sluggishly, I can do a quick
>> check of the status of everything without doing an uid change first.
>> I can check if I started the mail downloader at all with a mere ps
>> faux or pgrep fetchmail. Kernel threads using enormous amounts of CPU
>> time are visible to me without running top as root. etc
>
> Do you realize that you're basically repeating the talking points used
> by Microsoft when it originally released Windows OS?

Considering that absolutelyt nothing I wrote in the paragraph above
exists on Windows, that's a somewhat strange unsubstantiated statement.

[...]

> Linux / Unix / Solaris / etc are meant to be multi-user operating
> systems. Please remember that: multi-user.

The discussion was about "common use cases" and "single, physcial user
using a multi-user OS where different system users are used for
different purposes" is certainly a very common use case (while the
multiuser development server I mentioned earlier isn't).

> In the 1980's, Microsoft Windows decided to adopt your approach, and
> they have been back-pedaling ever since.

"In the 1980s", Microsoft was selling DOS for 16-bit computers. At the
same time, people very running seriously large time-shared UNIX(*)
installation which didn't hide the list of running processes from users.

[...]

> Likewise, Linux's design goal has never been to be a clone of your
> personal iOS devices.

I don't own any 'personal iOS devices'. I happen to have two laying
around here which are owned by my employer because I need them as client
for VPN testing. Not that this would matter anyhow.