Trouble doing a chmod under windows

[Davin Pearson]

I am trying to get write access to the Emacs file dir under the MS Windows operating system.

Here is the output of the chmod command:

c:\Program Files (x86)\emacs-24.5\share\info>chmod 666 dir
chmod: changing permissions of 'dir': Permission denied

What gives? How do I go about getting write access to the file "dir"?

[Paul]

You didn't say what version of MS Windows.

My guess would be something Vista or more recent.

The folder is owned by TrustedInstaller. It is
not owned by Administrator or by Davin. Program Files
is no longer recommended for this "random write" purpose.
If you need to store .ini files or other stuff, there
are AppData folders, Program Data, other parallel
tree structures for storing it. (This means the installer
has to be aware of the requirements and work in multiple
places during the installation.) One other disk area,
is wired up to the Roaming folder, so that writes
are seamless, but are not stored in the expected place.
All in the name of "security theater".

On an OS like Windows 10, you also cannot write to the
root of C:\ (that should return an error).

Ordinary users are not supposed to store content
in Program Files or Program files (x86).

TrustedInstaller is not even a full account. It does not
have a home directory. You cannot log into it. It exists
as a task, with the TrustedInstaller token. When the OS
detects an attempt to install something, it passes the
chore of loading Program Files, to something like
tiworker or similar. This only makes it more
difficult for ordinary users to do stuff. As it's
just a "multiple step process" to get around it.

*******

To see some of the lengths a person has to go
to, to work on modern Windows systems, have a look
at this example. It shows someone who took the time
and care, to put things back exactly as they found
them, without leaving any permanent damage while
working. This is not an example of your exact
scenario, but it does show something owned by
TrustedInstaller being dealt with. The "compact"
program happens to mess up the creator of the file
on the file system, so it requires a complete solution
to restore file ownership. They should have designed
"compact" so it preserved everything on its own,
and only changed the NTFS Compressed status of the
file. Because so many raw ends were left, it requires
the user to be an "IT grade" individual to run
a simple utility.

http://dandar3.blogspot.ca/2013/01/how-to-ntfs-compress-windows-winsxs.html

You can back up the permissions on the entire C: drive,
and restore them later with ICACLS, so that any modifications
you made to permissions, could be restored.

If you do decide to restore the permissions of the
entire C:\ , there is a little trick. The file where
the permissions are dumped, needs to be edited with
a text editor. The empty first line, needs to be replaced
with "." . And then, you can apply permissions to C:\ ,
without needing to be one directory level above C:\ .
Which I thought was a pretty stupid shortcoming. Good
thing the person here figured it out.

https://social.technet.microsoft.com/forums/windowsserver/en-US/8299036a-3cfe-40d7-beb8-becd2e56c2f4/icacls-syntax-issues-with-backup-restore

icacls c:\ /save ntfsCdrive.txt /t /c

Edit the ACL text file. The first line will be blank
signifying the current directory (which in this case happens
to be the root of the drive). Put a single period (.) in this line.

When restoring the ACL file, the restore command will correctly
interpret this to mean the current directory (since a single
period represents the current directory in most command syntaxes).

icacls c:\ /restore ntfsCdrive.txt

These are things I learned while breaking stuff :-)

HTH,
Paul

[Davin Pearson]

On Monday, June 13, 2016 at 1:50:16 PM UTC+12, Paul wrote:
> Davin Pearson wrote:
> > I am trying to get write access to the Emacs file dir under the MS Windows operating system.
> >
> > Here is the output of the chmod command:
> >
> > c:\Program Files (x86)\emacs-24.5\share\info>chmod 666 dir
> > chmod: changing permissions of 'dir': Permission denied
> >
> > What gives? How do I go about getting write access to the file "dir"?
>
> You didn't say what version of MS Windows.
>
> My guess would be something Vista or more recent.

I am running Windows 10...

> icacls c:\ /save ntfsCdrive.txt /t /c
>
> Edit the ACL text file. The first line will be blank
> signifying the current directory (which in this case happens
> to be the root of the drive). Put a single period (.) in this line.
>
> When restoring the ACL file, the restore command will correctly
> interpret this to mean the current directory (since a single
> period represents the current directory in most command syntaxes).
>
> icacls c:\ /restore ntfsCdrive.txt
>

Here is a fragment of the file generated by

icacls c:\ /save ntfsCdrive.txt /t /c

Note that I have added a period like you asked me to do.

What gives about the strange format of the file... so many null
characters. Are you sure that I have correctly followed your
instructions?

Here is a fragment of the output of running od -x on ntfsCdrive.txt

C:\Users\Davin Pearson>od -x ntfsCdrive.txt | head
0000000 0d2e 0a00 4400 3a00 5000 4100 4900 2800
0000020 4100 3b00 4f00 4900 4300 4900 3b00 4600
0000040 4100 3b00 3b00 3b00 4200 4100 2900 2800
0000060 4100 3b00 4f00 4900 4300 4900 3b00 4600
0000100 4100 3b00 3b00 3b00 5300 5900 2900 2800
0000120 4100 3b00 4f00 4900 4300 4900 3b00 3000
0000140 7800 3100 3200 3000 3000 6100 3900 3b00
0000160 3b00 3b00 4200 5500 2900 2800 4100 3b00
0000200 4f00 4900 4300 4900 4900 4f00 3b00 5300
0000220 4400 4700 5800 4700 5700 4700 5200 3b00

Here is the output of running the second command that you mentioned in
your email:

PS C:\Users\Davin Pearson> icacls c:\ /restore ntfsCdrive.txt
Not all privileges or groups referenced are assigned to the caller.
Successfully processed 0 files; Failed processing 0 files

It seems that nothing has been changed. So what am I doing wrong?

[Paul]

> C:\Uswers\Davin Pearson>od -x ntfsCdrive.txt | head

> 0000000 0d2e 0a00 4400 3a00 5000 4100 4900 2800
> 0000020 4100 3b00 4f00 4900 4300 4900 3b00 4600
> 0000040 4100 3b00 3b00 3b00 4200 4100 2900 2800
> 0000060 4100 3b00 4f00 4900 4300 4900 3b00 4600
> 0000100 4100 3b00 3b00 3b00 5300 5900 2900 2800
> 0000120 4100 3b00 4f00 4900 4300 4900 3b00 3000
> 0000140 7800 3100 3200 3000 3000 6100 3900 3b00
> 0000160 3b00 3b00 4200 5500 2900 2800 4100 3b00
> 0000200 4f00 4900 4300 4900 4900 4f00 3b00 5300
> 0000220 4400 4700 5800 4700 5700 4700 5200 3b00
>
> Here is the output of running the second command that you mentioned in
> your email:
>
> PS C:\Users\Davin Pearson> icacls c:\ /restore ntfsCdrive.txt
> Not all privileges or groups referenced are assigned to the caller.
> Successfully processed 0 files; Failed processing 0 files
>
> It seems that nothing has been changed. So what am I doing wrong?
>

To answer the first question, you need a text editor that
can handle wide (16 bit) characters. Notepad can do this.
I'm willing to bet, even the copy of Notepad in WINE
could do this.

After suitable manipulation (byte swap of the above), then
Windows 16 bit character to ASCII or so, gives text as follows.
That's what the above hex looks like, if interpreted as
16 bit character text. This is what I see in Notepad,
using your example. (I wrote a little AWK script to translate.)

.
D:PAI(A;OICI;FA;;;BA)(A;OICI;FA;;;SY)(A;OICI;0x1200a9;;;BU)(A;OICIIO;SDGXGWGR;

Now, if we break that down, each part in brackets is a separate item.
These are in the order of the Properties of the file, as
viewed in File Explorer. (When you view the security properties,
there will be at least four lines, and in the same order as these items.)
Now, using my secret decoder ring

https://msdn.microsoft.com/en-us/library/windows/desktop/aa379602(v=vs.85).aspx

(A;OICI;FA;;;BA) BUILTIN_ADMINISTRATORS
(A;OICI;FA;;;SY) LOCAL_SYSTEM [the SYSTEM account]
(A;OICI;0x1200a9;;;BU) BUILTIN_USERS
(A;OICIIO;SDGXGWGR; <--- missing a bit of the string on the end

The last one probably reads as

(A;OICIIO;SDGXGWGR;;;AU) AUTHENTICATED_USERS

Using the 0x1200a9 part, I can find the article by
Jesper Johansson, which does a better job of explaining
this stuff than I ever could.

https://technet.microsoft.com/en-us/magazine/2007.06.acl.aspx

Remember that the intention of the dump file, whether
applied to the entire C: or to a subsection, is for
restoration after you've "broken" things. You need a
utility that accepts symbolic arguments, if you want
to make small changes here and there. Editing the above file,
except to add the "." in place of the top line, isn't really
the intention.

*******

If you go back and look at the example here...

http://dandar3.blogspot.ca/2013/01/how-to-ntfs-compress-windows-winsxs.html

takeown /f "%WINDIR%\WinSxS" /r
icacls "%WINDIR%\WinSxS" /grant "%USERDOMAIN%\%USERNAME%":(F) /t

that kind of two-command stanza is typically used to
"smash" permissions. If you need to get something
done, and don't want to take "No" for an answer.

In Windows, we can even add those two, into a right-click
context menu item. Or, as a .bat file for script usage.
For example, the following two line script, accepts one parameter,
which is the "thing you want to own". The %1 is the command line parameter
being passed.

https://blogs.msdn.microsoft.com/tims/2006/11/10/windows-vista-secret-11-deleting-the-undeletable/

******* itsmine.cmd *******
takeown /f %1 /r /d y
icacls %1 /grant administrators:F /t

The following article, adds a new right-click context menu item.

These .reg files, if you right click them and select
"Merge", they get added to the Registry. Then, when
you right-click an item in File Explorer, you can add
yourself as an owner. Later, you could restore (remove)
the thing you changed, using your icacls dump.
Note: Do *not* apply this to the top of C:\ . This
is for working on small sections of the disk,
not as a means to turn the partition into your
own version of FAT32 (no permissions at all).

http://www.tenforums.com/tutorials/3841-take-ownership-add-context-menu-windows-10-a.html

If you're in a destructive mood, do a complete backup
of the drive before becoming immersed in this stuff.
It's OK to break things, if you have good backup images.

I expect, for the Takeown right-click menu thing
to work, your account should belong to "Administrators Group".
Which would be the default if you just set up Windows 10
with one account. The main account belongs to the
Administrators group. And that helps a lot with little
permission smashing exercises. Even if being a member
of Administrator group, does not directly allow you
to deal with TrustedInstaller ownership, you can see
that there are "plenty of hammers" for beating the
permissions into shape. A skilled artisan puts
everything back later, the way they found it.

And unlike MacOSX, Windows does not provide any sort
of "permission repair" for users. So after they've
been "TakeOwning" for a few weeks, you can clean it up.
I think MacOSX has something which can do that sort of
cleanup, restoring sane looking permissions. With Windows,
if you didn't use tools like the ICACLS dump/restore,
you'd probably have nothing to use as a substitute.
(In other words, you have to prepare in advance.)
I haven't seen evidence of any Windows "convenience" tool
for such a purpose (to undo the damage a user
belonging to the Administrators Group could do).

Paul

[Davin Pearson]

On Monday, June 13, 2016 at 6:57:34 PM UTC+12, Paul wrote:
> To answer the first question, you need a text editor that
> can handle wide (16 bit) characters. Notepad can do this.
> I'm willing to bet, even the copy of Notepad in WINE
> could do this.

Okay Notepad works to edit the file...

> After suitable manipulation (byte swap of the above), then
> Windows 16 bit character to ASCII or so, gives text as follows.
> That's what the above hex looks like, if interpreted as
> 16 bit character text. This is what I see in Notepad,
> using your example. (I wrote a little AWK script to translate.)

> D:PAI(A;OICI;FA;;;BA)(A;OICI;FA;;;SY)(A;OICI;0x1200a9;;;BU)(A;OICIIO;SDGXGWGR;

Is that an AWK script? It looks like line noise to me (I am unfamiliar with AWK).

> (A;OICI;FA;;;BA) BUILTIN_ADMINISTRATORS
> (A;OICI;FA;;;SY) LOCAL_SYSTEM [the SYSTEM account]
> (A;OICI;0x1200a9;;;BU) BUILTIN_USERS
> (A;OICIIO;SDGXGWGR; <--- missing a bit of the string on the end

Why the omission? I don't really know what you are talking about here...

>
> (A;OICIIO;SDGXGWGR;;;AU) AUTHENTICATED_USERS
>
> Using the 0x1200a9 part, I can find the article by
> Jesper Johansson, which does a better job of explaining
> this stuff than I ever could.

> Remember that the intention of the dump file, whether
> applied to the entire C: or to a subsection, is for
> restoration after you've "broken" things. You need a
> utility that accepts symbolic arguments, if you want
> to make small changes here and there. Editing the above file,
> except to add the "." in place of the top line, isn't really
> the intention.

> In Windows, we can even add those two, into a right-click
> context menu item. Or, as a .bat file for script usage.
> For example, the following two line script, accepts one parameter,
> which is the "thing you want to own". The %1 is the command line parameter
> being passed.

> ******* itsmine.cmd *******
> takeown /f %1 /r /d y
> icacls %1 /grant administrators:F /t

Here is the output of running your script on my dir file...

C:\home>takeown /f "c:\Program Files (x86)\emacs-24.5\share\info\dir" /r /d y
ERROR: The specified path is not a valid directory path.

C:\home>icacls "c:\Program Files (x86)\emacs-24.5\share\info\dir" /grant administrators:F /t
processed file: c:\Program Files (x86)\emacs-24.5\share\info\dir
Successfully processed 1 files; Failed processing 0 files

On the other hand, right clicking on the file "dir" in Windows Explorer brings up a dialog box and if you right click on Properties, then security, then Users, and then Edit and then clicking on the check box Full Control allows me to get read/write access to the file "dir", which is what I wanted in the first place.

[Paul]

And do you suppose that perhaps the "grant administrators"
is what allowed you to bring up the dialog box
and enter the full control ?

Things in Program Files belong to TrustedInstaller. There
should not be a user owning such a thing. This security
model exists for a reason.

Since you applied the commands in question to just the one folder,
you should be able to visit some other program folders and
see if you can give yourself Full control or not. If the
dialog box is not the same, then some step you carried out
has modified things.

*******

And no, the AWK script was not included. And since I byte-swapped
by hand and reformatted the data a bit first (before I started
writing the AWK script), the script isn't exactly ready for
public consumption. I can share it with you, for the general
principles. I used this to convert the content of your
hex editor paste, back into something I could test with
Notepad. Note that Win10 now has "bash shell" as a Windows
App Store package. It's present in Windows 10 Insider
edition 14361 or later or so. 10586 should not have it yet.
That would give you Gawk 4 series, which is slightly more
up-to-date. That's a suggestion if you don't know where
to find the old gnuwin32 packages.

*******

#00 41 00 3b
#
# Number of fields NF would be 4.
# Code extracted from gawk.pdf of gnuwin32 gawk 3.1.6 version.
# two character hex fields assumed, and I didn't add code
# to "chop and swap" your pasted text.

#Outputs bytes to file, converts from hex to byte_character

{
for (w=1; w<=NF; w++) {
n = length($w)
ret = 0
for (i = 1; i <= n; i++) {
c = substr($w, i, 1)
c = tolower(c)
if ((k = index("0123456789", c)) > 0)
k-- # adjust for 1-basing in awk
else if ((k = index("abcdef", c)) > 0)
k += 9
ret = ret * 16 + k
}
# nasty hack, just ignore the null bytes, as the
# line of text being converted is not a file name, so
# I could get away with this. Real file names, from
# customers around the world, would have enough exotic
# characters, this would be a mistake. I did this so
# the letters would be nicely packed next to one another.
# Not because this treatment is technically correct.
if (ret > 0) printf("%c", ret + 0)
}
}

Paul

[Barry Margolin]

In article <3c9363da-f984-4dab...@googlegroups.com>,

Why is this in comp.unix.programmer? It's about Windows, not Unix, and
it's about using command line utilities, not programming. And it's not
really even about the utility, but about filesystem permissions.

--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

[Davin Pearson]

On Tuesday, June 14, 2016 at 6:11:11 AM UTC+12, Barry Margolin wrote:
> In article <3c9363da-f984-4dab...@googlegroups.com>,

> Davin Pearson wrote:
>
> > I am trying to get write access to the Emacs file dir under the MS Windows
> > operating system.
> >
> > Here is the output of the chmod command:
> >
> > c:\Program Files (x86)\emacs-24.5\share\info>chmod 666 dir
> > chmod: changing permissions of 'dir': Permission denied
> >
> > What gives? How do I go about getting write access to the file "dir"?
>
> Why is this in comp.unix.programmer? It's about Windows, not Unix, and
> it's about using command line utilities, not programming. And it's not
> really even about the utility, but about filesystem permissions.

What newsgroup would you recommend I post this discussion to?

[Kaz Kylheku]

If you think this has anything to do with systems programming, the Windows
equivalent of "comp.unix.programmer" is "comp.os.ms-windows.programmer.win32".