Re: [Mingw-users] MingGW and OpenMP

[Renato S. <br....@gm...>]

2012/12/15 Eli Zaretskii <el...@gn...>

> The point is, if you act as a user that is not part of the
> Administrators group, and you enable a couple of privileges in the
> local policy, you avoid these prompts altogether, and still don't lose
> the UAC protection.
>

How come you keep UAC protection without the confirmation prompts?

 IOW, let me turn the table and ask you: in how many times, when you
> got the UAC prompt, did you say "nay, they are right, let's not do
> this dangerous thing" and clicked the "NO" button?  My guess is zero.
> That is, you _always_ decide that what you wanted to do needs to be
> done.
>

But for me that's much better than having no idea when and where those
elevated privileges are actually in use or not.


>  The UAC is a good thing, because it prevents programs invoked by other
> users, including all kinds of agents, be it benevolent or otherwise,
> acting without your explicit instructions.  But having these prompts
> for someone who is trusted to be a local administrator and the owner
> of the machine -- you -- is silly and evil, because it scares you into
> thinking you don't really know what you are doing, and prompts you to
> do stupid things in panic mode.
>

I don't think so, I like the UAC prompt because it tells me when stuff is
requiring higher privileges. It could be improved, for example it could
have a checkbox like "do not ask for this program again", then next time
just showing a pop-up in notification area that tells me that the program
is running in elevated mode. However, if you like or dislike UAC prompts,
it has nothing to do with adding yourself to the admin group versus giving
administrative permissions to your regular non-admin user all over the
place.

>
> The problem of running "as Administrator" is that it gives you all
> kinds of privileges you don't know about and don't normally want to
> have.  By contrast, allowing specific privileges in the local policy
> leaves you in control, because only those privileges are being
> granted.
>

The same can be said for the root user in unixes, and personally I don't
want to be that paranoid. I've been using the Administrators group for
years and I'm way far from getting so problematic as you are saying. Again,
I prefer to be notified (even if almost always answering yes to a dialog)
when elevated privileges needs to be acquired, than having these elevated
privileges enabled all the time.

 > Eli, as for the Program Files, in Windows 7 at least, programs running
> with
> > regular privileges that attempt to create files within Program Files will
> > get them redirected to a special VirtualStore folder within profile of
> > current user instead.
>
> Exactly, that's what I meant by "vitualized".  Next time the same
> program comes up, it will read the unmodified original files, as if
> the modifications were never done.
>

But you won't lose data, you should just notice that the program
misbehaves, which in fact is what they would be doing, since programs are
not supposed to write files to their own installation directory. A properly
designed program will write data to user profile or ProgramData.

Keith never said anything even remotely approaching this.  He said
> give the _MinGW_ user privileges over the _MinGW_ folder.  That's it,
> no "generalizations" of this rule intended anywhere.
>
>
As I said, that would mean that when you open a shell, you have the write
permissions everywhere in MinGW, all the time. That's way different from
having these same permissions only when you need them, e.g. when updating
MinGW, which is my whole point here. I don't think it's a good idea to give
your regular user write permissions over MinGW directory, I would create a
separate user for that, but since as I said the same principle can be
applied for all programs, I would end up with complicated permission and
user account changes and hence I prefer to just use the Administrators
group.

Ok, the Administrators group has much permissions scattered all over the
place as you said, but the same can be said for the root from unixes, which
has been around for decades. Also, if something gets really wrong when
running a program under too general elevated privileges (such as the admin
group), then I think it's more severely a problem of the program itself
than of the non-refined user/group approach.


> > Your point would also defeat the root user approach in Unix systems,
> > that's been there for decades, and that we're supposed to believe
> > it's sane, fine and wonderful.
>
> The "root user approach in Unix systems" is dead since the first day
> Unix-based systems started being used as personal computers.  E.g.,
> since installing anything on Unix requires root privileges, users now
> habitually do "sudo make install"; since looking at the system log
> also requires being root, they now do "sudo cat /var/log/messages";
> etc. etc.  Which all but defeats that model, because if you can always
> become root by typing 4 characters, why not be root all the time?
>

I don't understand quite well this objection, but answering to the
question: because you only want to acquire elevated privileges when you
actually need it, the reason why you run sudo. Besides, sudo/UAC is a
well-defined entry point though which you can keep track of the elevated
operations performed in the system, which is not possible to be done with
being root/admin all the time.

I see no difference between having write permissions always and having
> them only when you run mingw-get.  It's still the same you, the same
> programs written by someone else, and the same bugs or cockpit errors.
>

Same PBKC, same program, same bugs, sure. But you're not doing the same
things! 90% of the time, you don't need write privileges though all MinGW
tree, and that's the big difference. By acquiring the privileges only when
you actually need it (e.g. for mingw-get), you avoid all kind of problems
that would be associated with running MinGW in elevated mode to execute
tasks that do not require it at all (that is, your daily use of MinGW). For
example, an accidental rm -f / would completely damage your MinGW
installation if you have write permissions all the time (not so good
example but you get it), as opposed to damaging only your home dir or
similar.