mirror of
https://github.com/samba-team/samba.git
synced 2025-01-15 23:24:37 +03:00
bdee131f30
quite a large change as we had lots of code that assumed that objectSid was a string in S- format. metze and simo tried to convince me to use NDR format months ago, but I didn't listen, so its fair that I have the pain of fixing all the code now :-) This builds on the ldb_register_samba_handlers() and ldif handlers code I did earlier this week. There are still three parts of this conversion I have not finished: - the ltdb index records need to use the string form of the objectSid (to keep the DNs sane). Until that it done I have disabled indexing on objectSid, which is a big performance hit, but allows us to pass all our tests while I rejig the indexing system to use a externally supplied conversion function - I haven't yet put in place the code that allows client to use the "S-xxx-yyy" form for objectSid in ldap search expressions. w2k3 supports this, presumably by looking for the "S-" prefix to determine what type of objectSid form is being used by the client. I have been working on ways to handle this, but am not happy with them yet so they aren't part of this patch - I need to change pidl to generate push functions that take a "const void *" instead of a "void*" for the data pointer. That will fix the couple of new warnings this code generates. Luckily it many places the conversion to NDR formatted records actually simplified the code, as it means we no longer need as many calls to dom_sid_parse_talloc(). In some places it got more complex, but not many. (This used to be commit d40bc2fa8ddd43560315688eebdbe98bdd02756c)
This is the base of the new NTVFS subsystem for Samba. The model for NTVFS backends is quite different than for the older style VFS backends, in particular: - the NTVFS backends receive windows style file names, although they are in the unix charset (usually UTF8). This means the backend is responsible for mapping windows filename conventions to unix filename conventions if necessary - the NTVFS backends are responsible for changing effective UID before calling any OS local filesystem operations (if needed). The become_*() functions are provided to make this easier. - the NTVFS backends are responsible for resolving DFS paths - each NTVFS backend handles either disk, printer or IPC$ shares, rather than one backend handling all types - the entry points of the NTVFS backends correspond closely with basic SMB operations, wheres the old VFS was modelled directly on the POSIX filesystem interface. - the NTVFS backends are responsible for all semantic mappings, such as mapping dos file attributes, ACLs, file ownership and file times