Hi, 2015-06-25 21:58 GMT+02:00 Stefan (metze) Metzmacher <metze@xxxxxxxxx>: > Is that also the on disk representation? that's not the xattr representation, no. > I'm wondering if the size of an ace should be dynamic, > which might make it possible to support other ace types > in future. E.g. supporting other identities like 128-bit values > to make it easier to map Windows SIDS. I'm working on additionally supporting unmapped user@domain and group@domain identifier strings; we have to deal with that case in the nfs client; that may be useful for Samba as well. > Even without 128-bit ids, it would be very useful to mark an > ace so that it applies to a uid or gid at the same time. > This would reduce the size of the ace list when Samba uses > IDMAP_TYPE_BOTH, which means a SID is mapped to a unix id, which > is user (uid) and group (gid) at the same time. This feature is required > in order to support SID-Histories on accounts. > Currently Samba needs to add two aces (one uid and one gid) > in order to represent one Windows ace. It's not clear to me if supporting this would be a good idea right now. The kernel would have to treat each such entry like two separate entries internally. How would we map a combined user-space "uid + gid" number to a kernel uid and gid since it could map to two distinct numbers there? > I haven't looked at the claims based acls on Windows, but it would be > good if the new infrastructure is dynamic enough to support something > like that in a future version. I don't know, I have yet to see a use case that isn't totally crazy. Thanks, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
