FAQ SearchLogin
Tuxera Home
View unanswered posts | View active topics It is currently Sun Jun 13, 2021 13:45



Post new topic Reply to topic  [ 35 posts ]  Go to page Previous  1, 2
Applying WIM file to NTFS 
Author Message

Joined: Fri Aug 24, 2012 21:18
Posts: 30
Post Re: Applying WIM file to NTFS
In ntfs_set_file_attributes():

Code:
/* Win32 convention here : -1 means successful */
if (!ntfs_set_inode_attributes(ni, attrib))
       res = -1;
if (!ntfs_inode_close(ni))
       res = -1;


If we fail to set the inode attributes but successfully close the inode, the function call was not successful. So maybe change it to

Code:
/* Win32 convention here : -1 means successful */
if (!ntfs_set_inode_attributes(ni, attrib))
       res = -1;
if (ntfs_inode_close(ni))
       res = 0;


Thu Aug 30, 2012 18:33
Profile

Joined: Fri Aug 24, 2012 21:18
Posts: 30
Post Re: Applying WIM file to NTFS
Here's a new patch, based off the original code.

I realize there is some confusion about the return values of the functions. For example I guess I am thinking that ntfs_get_inode_security() should have the same return value (i.e. security ID > 0, or 0 if unsuccessful, or -1 if no security ID) as ntfs_get_file_security(). Otherwise the security ID wouldn't be returned anywhere.

This isn't quite the case with ntfs_set_inode_security() and ntfs_set_inode_attributes(), which return the opposite of the file versions. But I guess that's okay, since we only want to use the Windows convention when necessary.


Attachments:
new_wim_patches.gz [2.62 KiB]
Downloaded 754 times
Thu Aug 30, 2012 19:12
Profile
NTFS-3G Lead Developer

Joined: Tue Sep 04, 2007 17:22
Posts: 1286
Post Re: Applying WIM file to NTFS
Hi,

Thank you for reviewing the patch proposal and exhibiting errors. I am taking them into account.
Quote:
should we allow the DACL (in addition to the SACL) to have no ACE's as well? I haven't noticed this issue, but this may be more consistent

Big question : if this can be the case, is there a special meaning ? Normally all files have at least an ACE allowing the system to access the file... I am keeping this possibility out for the time being.
Quote:
I realize there is some confusion about the return values of the functions.

Indeed.

Your needs are similar to interfaces which were designed for compatibility with Windows (which I do not want to change without checking Windows behavior). Using both Windows conventions and Linux conventions in the same code is confusing and prone to errors, this is why my proposal was turned to Linux conventions. Your proposal leads to possible deviations from Windows in the compatibility-oriented interfaces (I have to check whether *psize should be changed in case of error, or what is returned by GetFileAttributes() on errors).

Also, defining the ACL field selection and the attributes as u32 may look weird, I suggest defining them as unsigned ints.

Finally some parts of the new code were within conditional code, which is not desirable.

Based on this, I will make a new proposal later.

Quote:
I'm going to make it possible to build wimlib using either NTFS-3g from 2012-1-15 or the new version with the patches

Your needs are probably covered by existing code, though you may have to provide a security context, meaningless in your case apart from the field "vol" which you would have to fill in.

Regards

Jean-Pierre


Fri Aug 31, 2012 10:48
Profile

Joined: Fri Aug 24, 2012 21:18
Posts: 30
Post Re: Applying WIM file to NTFS
Hi,

The Windows compatibility of the old interfaces definitely should be maintained, so anything you need to do to make that happen is fine.

Since the attributes and security descriptors are properties of an inode, it makes sense to have functions that get and set them to/from an inode; however, if it will cause confusion due to having the Windows-compatible interfaces as well, then perhaps it's best not to include them.

You know, maybe I should be using the extended attributes interface instead. It probably would be easier, although I always like to imagine the worst-case scenarios (for example, if someone wrote a gigabyte of data into an alternate data stream, it would all have to be in memory at the same time to use {get,set}xattr()).

Thanks!


Fri Aug 31, 2012 15:58
Profile
NTFS-3G Lead Developer

Joined: Tue Sep 04, 2007 17:22
Posts: 1286
Post Re: Applying WIM file to NTFS
Hi,

Quote:
if it will cause confusion due to having the Windows-compatible interfaces as well, then perhaps it's best not to include them.

I meant I would like to restrict Windows type interfaces (0 meaning failure) to programs which have a dual Windows/Linux version. Of course a real need may dictate otherwise.
Quote:
You know, maybe I should be using the extended attributes interface instead.

The interfaces in xattrs.c are not far from what you need (apart from the security context which you have to populate), and they are available in all not-too-old releases of ntfs-3g.

Maybe I freeze the patches to security.c until we make a final decision about it ? (I keep the patch for the void SACL).
Quote:
if someone wrote a gigabyte of data into an alternate data stream, it would all have to be in memory at the same time to use {get,set}xattr())

This is not possible. Extended attributes are limited by the kernel to 65536 bytes (a Windows ads may contain gigabytes though). Were you not using ntfs_attr_pwrite() for an ads ?

Regards

Jean-Pierre


Fri Aug 31, 2012 18:46
Profile

Joined: Fri Aug 24, 2012 21:18
Posts: 30
Post Re: Applying WIM file to NTFS
Hi,

With regards to the xattr interface, I was considering the possibility of getting and setting the NTFS-specific data (attributes, security descriptor, DOS name, NTFS timestamps, reparse data, and named data streams) entirely through using the l{get,set,list}xattr() functions on a mounted NTFS filesystem. If this method were to be used, wimlib would not even need to be linked to libntfs-3g. In fact, just yesterday I was using this method in the NTFS capture/apply test suite I was writing. Basically, each test is to construct a test NTFS volume, then capture and apply it and fully compare the applied volume with the original. The xattr interface is used to read NTFS-specific data, and libntfs-3g is not used directly.

Yes, I am currently writing and reading the named data streams directly using libntfs-3g (ntfs_attr_pwrite(), ntfs_attr_pread()). If extended attributes are in fact limited to 65536 bytes, then the xattr interface cannot be used to correctly read and write the named data streams in the general case. Perhaps I could require that the Windows stream interface be used instead? xattrs would still have to be used for timestamps etc. though.

Anyway, if I stick with using libntfs-3g directly, I suppose it would also be possible to initialize the SECURITY_API structure manually, then set/get the file attributes and security data with ntfs_{set,get}_file_{security,attributes}(). To avoid issues with inode opening and closing this probably should be done in a separate pass through the dentry tree. I don't think there really would be any issues with doing it this way, other than the hack of filling in the SECURITY_API manually. So if you don't think it would improve libntfs-3g to add the inode versions of these functions, I can definitely do it this way, and probably I should have the code to do so anyway so it will work with older versions of libntfs-3g without having to clone code from a specific version.

I believe it also would be possible to work around the problem with the empty SACL (at least for version of libntfs-3g without the patch) by removing the SACL from the security descriptor.


Fri Aug 31, 2012 20:33
Profile
NTFS-3G Lead Developer

Joined: Tue Sep 04, 2007 17:22
Posts: 1286
Post Re: Applying WIM file to NTFS
Hi,

Quote:
Perhaps I could require that the Windows stream interface be used instead? xattrs would still have to be used for timestamps etc. though.

These choices are independent. xattrs can be used with the Windows stream interface.
Quote:
I don't think there really would be any issues with doing it this way, other than the hack of filling in the SECURITY_API manually.

No, do not use the security api, use the interfaces in xattrs.c, typically ntfs_xattr_system_setxattr(), which capture all the fields you need. You will have to zero all the fields in "struct SECURITY_CONTEXT*" apart from the "vol" (which you can get from ni->vol). In essence this means you want to bypass the access control to the targeted fields.

Regards

Jean-Pierre


Fri Aug 31, 2012 21:34
Profile

Joined: Fri Aug 24, 2012 21:18
Posts: 30
Post Re: Applying WIM file to NTFS
Quote:
No, do not use the security api, use the interfaces in xattrs.c, typically ntfs_xattr_system_setxattr()


Ah, I see how it can be done now. From ntfs_xattr_system_{set,get}xattr(), the functions ntfs_{set,get}_ntfs_{acl,attrib}() will be called, which are quite similar to what I wanted in the first place with the inodes anyway. So if this works, the inode functions wouldn't even be needed.


Fri Aug 31, 2012 22:10
Profile

Joined: Fri Aug 24, 2012 21:18
Posts: 30
Post Re: Applying WIM file to NTFS
Hi,

I've implemented setting and getting the file attributes and security by using ntfs_xattr_system_setxattr() and ntfs_xattr_system_getxattr(), respectively. It seems to work fine; it passed all the test cases, and I'm testing it on a full Windows image now. In addition, I was able to remove the code that I had cloned from libntfs-3g, and the code even works with the libntfs-3g released 2011-4-12 (but not with the version from 2010-3-6, which doesn't have the needed functions available).

By the way, I might be missing something, but I couldn't find links to the older versions of ntfs-3g anywhere on tuxera.com, so I downloaded them from an Ubuntu archive instead. Shouldn't the releases be linked to on the release history page or something?

I am working around the empty SACL issue by identifying security descriptors where the SACL offset is equal to the size of the security descriptor minus sizeof(ACL), and setting the SACL offset to 0 and decreasing the size of the descriptor by sizeof(ACL), effectively removing the SACL. Having no SACL should be the same as a SACL with no entries, right?

Thanks for all the help!


Sat Sep 01, 2012 16:52
Profile
NTFS-3G Lead Developer

Joined: Tue Sep 04, 2007 17:22
Posts: 1286
Post Re: Applying WIM file to NTFS
Hi,

Quote:
It seems to work fine; it passed all the test cases, and I'm testing it on a full Windows image now

Great !
Quote:
I couldn't find links to the older versions of ntfs-3g anywhere on tuxera.com, so I downloaded them from an Ubuntu archive instead. Shouldn't the releases be linked to on the release history page or something?

It is Tuxera policy not to make older releases available, I cannot do anything about it. Anyway you can get them from most distributions archives.
Quote:
Having no SACL should be the same as a SACL with no entries, right?

This is not documented... you have to test.

Regards

Jean-Pierre


Sun Sep 02, 2012 08:37
Profile
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 35 posts ]  Go to page Previous  1, 2


Who is online

Users browsing this forum: No registered users and 2 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.