FAQ • Search • Login
Tuxera Home
View unanswered posts | View active topics It is currently Mon Apr 12, 2021 21:48

Board index » NTFS-3G Support » Usage Questions & Problems on Linux

All times are UTC + 2 hours




Post new topic Reply to topic  Page 1 of 1
  [ 11 posts ] 
Previous topic | Next topic 
Possible BUG when editing UserMapping 
Author Message
UlfZibis

Joined: Mon Mar 31, 2014 13:43
Posts: 113
Post Possible BUG when editing UserMapping
Initial state:
Code:
ich@ThinkPad-T500:/mnt/Daten/.NTFS-3G$ ntfs-3g.secaudit -v UserMapping
secaudit 1.4.2 : NTFS security data auditing
File UserMapping
        000000  01000484 60000000 70000000 00000000
        000010  14000000 02004c00 03000000 00101800
        000020  ff011f00 01020000 00000005 20000000
        000030  20020000 00101400 ff011f00 01010000
        000040  00000005 12000000 00101800 a9001200
        000050  01020000 00000005 20000000 21020000
        000060  01020000 00000005 20000000 20020000
        000070  01050000 00000005 15000000 647f0a93
        000080  0d02ff2a 56280d32 01020000
Computed hash : 0x12d044f3
Windows attrib : 0x24
Windows owner S-1-5-32-544
Windows group S-1-5-21-2466938724-721355277-839723094-513
Interpreted Unix owner 0, group 1999, mode 0755
No errors were found

Then I edited with:
Quote:
gksudo geany /mnt/Daten/.NTFS-3G/UserMapping

On save I got an error like "error on cutting ...", syslog:
Code:
Nov 19 12:58:03 ThinkPad-T500 org.freedesktop.FileManager1[1636]: geany: Fatal IO error 0 (Erfolg) on X server :0.0.
Nov 19 12:58:36 ThinkPad-T500 org.freedesktop.FileManager1[1636]: (nemo:6542): Gtk-CRITICAL **: gtk_action_group_get_action: assertion 'GTK_IS_ACTION_GROUP (action_group)' failed
Nov 19 12:58:36 ThinkPad-T500 org.freedesktop.FileManager1[1636]: sys:1: Warning: g_object_set: assertion 'G_IS_OBJECT (object)' failed
Nov 19 12:58:36 ThinkPad-T500 org.freedesktop.FileManager1[1636]: (nemo:6542): Gtk-CRITICAL **: gtk_action_set_sensitive: assertion 'GTK_IS_ACTION (action)' failed
Nov 19 12:58:36 ThinkPad-T500 org.freedesktop.FileManager1[1636]: (nemo:6542): Gtk-CRITICAL **: gtk_action_group_get_action: assertion 'GTK_IS_ACTION_GROUP (action_group)' failed
Nov 19 12:58:36 ThinkPad-T500 org.freedesktop.FileManager1[1636]: (nemo:6542): Gtk-CRITICAL **: gtk_action_set_sensitive: assertion 'GTK_IS_ACTION (action)' failed

After the UserMapping was of size 0.
Then I tried:
Code:
ich@ThinkPad-T500:/mnt/Daten/.NTFS-3G$ ntfs-3g.secaudit -v .
secaudit 1.4.2 : NTFS security data auditing
Directory .
        000000  01000494 60000000 70000000 00000000
        000010  14000000 02004c00 03000000 00031800
        000020  ff011f00 01020000 00000005 20000000
        000030  20020000 00031400 ff011f00 01010000
        000040  00000005 12000000 00031800 a9001200
        000050  01020000 00000005 20000000 21020000
        000060  01020000 00000005 20000000 20020000
        000070  01050000 00000005 15000000 647f0a93
        000080  0d02ff2a 56280d32 01020000
Computed hash : 0xebd03c76
Windows attrib : 0x36
Windows owner S-1-5-32-544
Windows group S-1-5-21-2466938724-721355277-839723094-513
Interpreted Unix owner 0, group 0, mode 0755
No errors were found

Note, that the Interpreted Unix group is now 0 instead 1999.
It seems, that ntfs-3g doesn't cache the user mapping with mount, but retrieves it newly on any file system operation, so editing UserMapping results in a kind of crash.

The original UserMapping was:
Code:
w7chef::S-1-5-21-2466938724-721355277-839723094-1000
w7homeusers::S-1-5-21-2466938724-721355277-839723094-1001
ich::S-1-5-21-2466938724-721355277-839723094-1003
:windows:S-1-5-21-2466938724-721355277-839723094-513
::S-1-5-21-2466938724-721355277-839723094-10000
# sudo addgroup --gid 1999 windows
#   windows group not added to users
# fstab: ... /mmt/Daten ntfs defaults,inherit,windows_names,hide_dot_files 0 0
#     ... /mnt/Windows7 ntfs defaults,noauto,inherit,windows_names,hide_dot_files 0 0

-Ulf
Thu Nov 19, 2015 15:50
Profile
UlfZibis

Joined: Mon Mar 31, 2014 13:43
Posts: 113
Post Re: Possible BUG when editing UserMapping
With this behaviour it is difficult to do tests according Understanding group / owner pair in UserMapping
I use ntfs-3g 2015.3.14 integrated FUSE 27 on Ubuntu amd64 15.04.
Thu Nov 19, 2015 18:32
Profile
jpa
NTFS-3G Lead Developer

Joined: Tue Sep 04, 2007 17:22
Posts: 1286
Post Re: Possible BUG when editing UserMapping
Hi,

Quote:
With this behaviour it is difficult to do tests according Understanding group / owner pair in UserMapping

To display how your users and groups are organized :
please connect as user "w7chef" and type the command "id",
then connect as user "w7homeusers" and type the command "id",
then connect as user "ich" and type the command "id".

Below is a sample scenario probably similar to yours :

User mapping file :
Code:
[root@openindiana master]# cat disk/.NTFS-3G/UserMapping
# Three users : first (uid 111), second (uid 112) and third (uid 113)
# two groups : staff (gid 10) and guest (gid 15)
111::S-1-5-21-2271520284-214583110-2989893066-1001
112::S-1-5-21-2271520284-214583110-2989893066-1002
113::S-1-5-21-2271520284-214583110-2989893066-1003
:10:S-1-5-21-2271520284-214583110-2989893066-513
:15:S-1-5-21-2271520284-214583110-2989893066-1003

First stage, each user creates his/her own file, moreover users first and third create another file to be put in another group later.
Code:
[root@openindiana master]# su first
[master@openindiana master]$ id
uid=111(first) gid=10(staff) groups=10(staff)
[master@openindiana master]$ touch disk/file.first
[master@openindiana master]$ touch disk/file.first.change
[master@openindiana master]$ exit
exit

[root@openindiana master]# su second
[master@openindiana master]$ id
uid=112(second) gid=10(staff) groups=10(staff)
[master@openindiana master]$ touch disk/file.second
[master@openindiana master]$ exit
exit

[root@openindiana master]# su third
[master@openindiana master]$ id
uid=113(third) gid=15(guest) groups=15(guest)
[master@openindiana master]$ touch disk/file.third
[master@openindiana master]$ touch disk/file.third.change
[master@openindiana master]$ exit
exit

Second stage : change the groups for file.first.change and file.third.change
Code:
[root@openindiana master]# ls -l disk
total 0
-rw-r--r--   1 first    staff          0 Nov 19 09:25 file.first
-rw-r--r--   1 first    staff          0 Nov 19 09:26 file.first.change
-rw-r--r--   1 second   staff          0 Nov 19 09:33 file.second
-rw-r--r--   1 third    guest          0 Nov 19 09:34 file.third
-rw-r--r--   1 third    guest          0 Nov 19 09:34 file.third.change
[root@openindiana master]# chgrp guest disk/file.first.change
[root@openindiana master]# chgrp staff disk/file.third.change
[root@openindiana master]# ls -l disk
total 0
-rw-r--r--   1 first    staff          0 Nov 19 09:25 file.first
-rw-r--r--   1 first    guest          0 Nov 19 09:26 file.first.change
-rw-r--r--   1 second   staff          0 Nov 19 09:33 file.second
-rw-r--r--   1 third    guest          0 Nov 19 09:34 file.third
-rw-r--r--   1 third    staff          0 Nov 19 09:34 file.third.change

Now the resulting owner SID and group SID :
Code:
[root@openindiana ntfslowprof]# secaudit /home/master/try.ntfs file.first
secaudit 1.4.6 : NTFS security data auditing
"/home/master/try.ntfs" opened
File file.first : key 0x102
Windows attrib : 0x20
Windows owner S-1-5-21-2271520284-214583110-2989893066-1001
Windows group S-1-5-21-2271520284-214583110-2989893066-513
Interpreted Unix owner 111, group 10, mode 0644
"/home/master/try.ntfs" closed
No errors were found
[root@openindiana ntfslowprof]# secaudit /home/master/try.ntfs file.first.change
secaudit 1.4.6 : NTFS security data auditing
"/home/master/try.ntfs" opened
File file.first.change : key 0x107
Windows attrib : 0x20
Windows owner S-1-5-21-2271520284-214583110-2989893066-1001
Windows group S-1-5-21-2271520284-214583110-2989893066-1003
Interpreted Unix owner 111, group 15, mode 0644
"/home/master/try.ntfs" closed
No errors were found
[root@openindiana ntfslowprof]# secaudit /home/master/try.ntfs file.second
secaudit 1.4.6 : NTFS security data auditing
"/home/master/try.ntfs" opened
File file.second : key 0x103
Windows attrib : 0x20
Windows owner S-1-5-21-2271520284-214583110-2989893066-1002
Windows group S-1-5-21-2271520284-214583110-2989893066-513
Interpreted Unix owner 112, group 10, mode 0644
"/home/master/try.ntfs" closed
No errors were found
[root@openindiana ntfslowprof]# secaudit /home/master/try.ntfs file.third
secaudit 1.4.6 : NTFS security data auditing
"/home/master/try.ntfs" opened
File file.third : key 0x104
Windows attrib : 0x20
Windows owner S-1-5-21-2271520284-214583110-2989893066-1003
Windows group S-1-5-21-2271520284-214583110-2989893066-1003
Interpreted Unix owner 113, group 15, mode 0644
"/home/master/try.ntfs" closed
No errors were found
[root@openindiana ntfslowprof]# secaudit /home/master/try.ntfs file.third.change
secaudit 1.4.6 : NTFS security data auditing
"/home/master/try.ntfs" opened
File file.third.change : key 0x108
Windows attrib : 0x20
Windows owner S-1-5-21-2271520284-214583110-2989893066-1003
Windows group S-1-5-21-2271520284-214583110-2989893066-513
Interpreted Unix owner 113, group 10, mode 0644
"/home/master/try.ntfs" closed
No errors were found

Regards

Jean-Pierre
Thu Nov 19, 2015 20:47
Profile
UlfZibis

Joined: Mon Mar 31, 2014 13:43
Posts: 113
Post Re: Possible BUG when editing UserMapping
UlfZibis wrote:
It seems, that ntfs-3g doesn't cache the user mapping with mount, but retrieves it newly on any file system operation, so editing UserMapping results in a kind of crash.

With this behaviour it is difficult to do tests according Understanding group / owner pair in UserMapping
I use ntfs-3g 2015.3.14 integrated FUSE 27 on Ubuntu amd64 15.04.

Now I tried again with:
Code:
ich@ThinkPad-T500:/mnt$ ntfs-3g.secaudit -v Daten/.NTFS-3G/UserMapping
secaudit 1.4.2 : NTFS security data auditing
File Daten/.NTFS-3G/UserMapping
        000000  01000484 60000000 70000000 00000000
        000010  14000000 02004c00 03000000 00101800
        000020  ff011f00 01020000 00000005 20000000
        000030  20020000 00101400 ff011f00 01010000
        000040  00000005 12000000 00101800 a9001200
        000050  01020000 00000005 20000000 21020000
        000060  01020000 00000005 20000000 20020000
        000070  01020000 00000005 20000000 20020000
Computed hash : 0x07d0d652
Windows attrib : 0x20
Windows owner S-1-5-32-544
Windows group S-1-5-32-544
Interpreted Unix owner 0, group 0, mode 0755
No errors were found


Now I'm successfully able to edit /mnt/Daten/.NTFS-3G/UserMapping with Geany.
Note the little differences:
Windows attrib : 0x20
Windows group S-1-5-32-544
(This time I created the file with Linux, not with Windows, not setting the SYSTEM attribute.)
Does that matter ?
May be my experienced crash with Geany was just random ???

Thanks for your exhaustive examples, I will deal with that later.
-Ulf
Fri Nov 20, 2015 00:47
Profile
UlfZibis

Joined: Mon Mar 31, 2014 13:43
Posts: 113
Post Re: Possible BUG when editing UserMapping
Note that w7chef and w7homeusers are only dummies for later use, they currently do not exist on my Ubuntu system.
On the Windows 7 Installation:
Chef (...-1000) is the administrative user.
HomeUser (...-1001) is the "virtual" owner for the home network.
ich (...-1003) is the standard user with restricted privileges for daily work.

Currently I do not have other users on both systems, but they may be installed later.

-Ulf
Fri Nov 20, 2015 01:22
Profile
UlfZibis

Joined: Mon Mar 31, 2014 13:43
Posts: 113
Post Re: Possible BUG when editing UserMapping
About your exhaustive examples, I guess you have misunderstood my subject.
Sorry for your efforts.

-Ulf
Fri Nov 20, 2015 06:01
Profile
jpa
NTFS-3G Lead Developer

Joined: Tue Sep 04, 2007 17:22
Posts: 1286
Post Re: Possible BUG when editing UserMapping
Hi,

Quote:
(This time I created the file with Linux, not with Windows, not setting the SYSTEM attribute.)
Does that matter ?

Better not meddle with system and hidden attributes, they have special meanings.

Quote:
Note that w7chef and w7homeusers are only dummies for later use, they currently do not exist on my Ubuntu system.

Then you cannot map them.

Regards

Jean-Pierre
Fri Nov 20, 2015 09:15
Profile
UlfZibis

Joined: Mon Mar 31, 2014 13:43
Posts: 113
Post Re: Possible BUG when editing UserMapping
Hi,

Quote:
Better not meddle with system and hidden attributes, they have special meanings.
Sorry for nit picking, I suppose there are good reasons to make use of these attributes on Windows, otherwise they would not exist. What I wanted to know, if NTFS-3G behaves different on editing a file while facing a system attribute.

Quote:
Then you cannot map them.
Correct, this was not intended, sorry for the confusion.

Thanks,
Ulf
Fri Nov 20, 2015 19:50
Profile
UlfZibis

Joined: Mon Mar 31, 2014 13:43
Posts: 113
Post Re: Possible BUG when editing UserMapping
Hi Jean-Pierre,
maybe you have overseen my question in the 2nd sentence:
UlfZibis wrote:
... What I want to know, if NTFS-3G behaves different on editing a file while facing a system attribute.


Thanks,
Ulf
Mon Nov 23, 2015 13:46
Profile
jpa
NTFS-3G Lead Developer

Joined: Tue Sep 04, 2007 17:22
Posts: 1286
Post Re: Possible BUG when editing UserMapping
Hi,

Quote:
maybe you have overseen my question in the 2nd sentence:
UlfZibis wrote:
Quote:
... What I want to know, if NTFS-3G behaves different on editing a file while facing a system attribute.

System and hidden attributes may mean a symlink, a socket, a pipe, a device... so do not change them.

Regards

Jean-Pierre
Mon Nov 23, 2015 14:31
Profile
UlfZibis

Joined: Mon Mar 31, 2014 13:43
Posts: 113
Post Re: Possible BUG when editing UserMapping
Hi,
jpa wrote:
UlfZibis wrote:
... What I want to know, if NTFS-3G behaves different on editing a file while facing a system attribute.

System and hidden attributes may mean a symlink, a socket, a pipe, a device... so do not change them.

I didn't really change something, I only created a folder and file, namely .NTFS-3G/UserMapping, flagged with system and hidden attribute. The reason is to hide it from the normal user like "System Volume Information", even "display hidden files" is enabled, and prevent from unintentional corruption/deletion.

Now I did a 2nd try and I didn't have a crash again, but the system attribute was deleted. It also resolves my worry about if the UserMapping isn't cached from mount.
I really would appreciate, if you could outline the special behaviour with Windows attributes, also with the archive bit, in the NTFS-3G docs. Otherwise people could assume, they are ignored and never changed.
Mon Nov 23, 2015 23:11
Profile
Display posts from previous:  Sort by  
Post new topic Reply to topic  Page 1 of 1
  [ 11 posts ] 

Board index » NTFS-3G Support » Usage Questions & Problems on Linux

All times are UTC + 2 hours


Who is online

Users browsing this forum: Google [Bot] and 3 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Original forum style by Vjacheslav Trushkin.