On 08/24/11 20:06, Marc Bevand wrote:
Yes, I have "ad": $ grep -w ad /etc/nsswitch.conf passwd: files ad
group: files ad
My problem is not caused by tmpfs, because I observe the same behavior
with zfs.
Hmm. That's odd.
Something else that disproves your theory (sorry :D) is that tmpfs is
perfectly capable of recording AD ownership: I can "chown
myu...@example.com /tmp/file" as root (which makes sense because a
filesystem only sees 32-bit UIDs; it doesn't care if they are
ephemeral).
Yeah, I guess that might well work. Like I said, this is uncharted territory.
Even more puzzling: after creating a local Unix account 'myuser'
matching the AD account name (so that idmap bidirectionally maps them),
my commands end up with the file owned by 'nobody' on tmpfs but 'myuser'
on zfs. Why does zfs behave differently when this local account exists?
The ZFS behavior is easy to explain. If there's a mapping between the
Windows account and the UNIX account, we use the UNIX account in file metadata.
The tmpfs behavior... don't know. We "know" that tmpfs doesn't support
ephemeral IDs, but as you say it might well not *need* to support them; if
it just keeps the ephemeral IDs around they should be good until the system
is rebooted.
Actually, as a workaround, creating local accounts is fine for my needs.
But I would definitely like an explanation of what is going on with
these ephemeral IDs... I suspect Solaris has a code path that, sometimes
but not always, intentionally maps them to nobody, when the right thing
to do would be to not interfere with them (ie. pass them as is to the
filesystem).
Entirely possible. Although ephemeral IDs are a pretty general concept and
the system comes close to supporting them across the board, they have only
been tested and exercised in some relatively constrained scenarios.
[ later ] ... and indeed, I've found the very code that does that mapping.
I don't immediately see why ZFS is triggering that code; on its face, it
shouldn't be.
Anyhow, the summary is that while it's fascinating to see how far you can
get with a shell that's logged in as a Windows user, a shell (or for that
matter any process) running as a Windows user isn't a supported case, and
"su as root" is a loophole that we hadn't thought of.
_______________________________________________
cifs-discuss mailing list
cifs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
