/usr/local, /var and */tmp in c:\Users\Public
Fri Nov 14 01:05:00 GMT 2014
On 14/11/14 08:30, Corinna Vinschen wrote:
> On Nov 13 14:09, Warren Young wrote:
>> On Nov 13, 2014, at 2:33 AM, Corinna Vinschen <firstname.lastname@example.org> wrote:
>>> On Nov 12 17:19, Warren Young wrote:
>>>> Iâm not advocating that step so early, but maybe if this breakup does
>>>> happen, a few years later setup.exe can start applying some strong
>>>> ACLs to files it writes.
>>> ??? What "strong" ACLs?
>> The ones that are not there right now. :)
>> Just to pick a random example:
>> $ ls -l /bin/ls.exe
>> -rwxrwxr-x 1 Warren None 116253 Oct 13 10:12 /bin/ls.exe
>> The same fileâs permissions, from Windowsâ perspective:
> icacls output would be more helpful than a picture.
> However, this isn't really a problem. The group permissions are
> apparently faked by Cygwin, they don't reflect the reality. I just
> don't remember why this is done, it's probably old. Have to check...
>> So, just because I installed Cygwin with my regular user account, I
>> get permission to rewrite ls.exe. This is not a good thing, if our
>> goal is to make Cygwin work like Linux while working *within* the
>> Windows environment.
>> IMHO, the way to meet both goals simultaneously is to put programs in
>> c:\Program Files,
> No, sorry, but no. We're certainly not going to turn everything upside
> down installation-wise. If you want Cygwin installed into Program
> Files, just change it in the GUI.
>> and to give full-control perms to the local
>> Administrator account in the SAM case, or possibly the domain one in
>> the AD case.
> BTDT. The code is still in Setup, just doesn't run anymore. The idea
> was to install with user and group set to Administator/ Administrators,
> but we had some complaints and the code got deactivated. We can
> reactivate the Administrators group, but that still requires to run
> Setup elevated. It doesn't work when running under a non-admin account.
> However, the *other* idea is that if you install with an elevated Setup,
> your account is an admin account anyway. Ideally when you install
> Cygwin for multiple users, you're using an account you're not using for
> daily usage.
If you read back through some of my emails to this list, you'll see that
this is exactly the setup I adopted some time back. It is also why I
contributed the -B switch to setup.
What the OP is asking for has always been available. And it is
analogous with Unix.
What I do is:
1) create a non-admin user named portapps.
3) runas /user:portapps cmd
4) as portapps, run c:\Program Files\7zip\7zFM to give me a graphical
way to navigate the filesystem and create folders.
5) Create a folder c:\Users\Public\portapps.
6) Adjust the permissions on that folder so that inheritance from
c:\Users\Public is broken, and inherited permissions with portapps
FullControl and Everyone read/execute (I'm talking Windows perms
7) Now I run setup-x86(_64) -B still as portapps from cmd, install to
8) That's it. Now my regular user can run
c:\User\Public\portapps\cygwin\bin\mintty - and cannot accidentally
overwrite /bin, /etc or anything like that. All software
administration (install, /etc config) is done via portapps user.
9) This is no different to unix/linux, where you'd have to do
sudo apt-get install, or sudo yum install, or sudo vi /etc/profile
etc.... portapps is almost equal to root.
10) If you want to do Windows privileged stuff, you'll have to run
those in an elevated mintty. Of course there is still the danger of
overwriting /bin there. But if you are limiting doing that to just
things like ssh-host-config etc, than it's fine. Also best to have
a separate admin account to your account if possible.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
More information about the Cygwin