unpack_nt_owners fails with owner S-1-5-32-544

[tridge at samba.org]

Simo,

 > Well, on this, with regard to ACEs, I disagree.
 > Windows have SIDs, which have no "sex". it doesn't matter if they are
 > users or groups or something else at all, and this is the key difference
 > that bites us.

user sids and groups sids are not the same thing even on windows. The
things you can do with them are different, so for example a user can't
'contain' other users, but a group can contain other users/groups.

So they do have a 'sex' (hmm, I wonder how many people won't see this
discussion due to overactive spam filters??).

 > Said that, I want to see a decent solution of course, which I think can
 > even be to accept there is nothing we can do with some unknown SIDs.

we can work with them easily. We can't completely prevent all denial
of service attacks, but (as I noted in an email to the team last
week), there are any number of denial of service attacks possible
against Samba and just about any other networked service. If we didn't
implement something just because a DOS is possible we'd never
implement anything at all! 

heck, it would be trivial for any authenticated user to DOS an
existing Samba3 system. It would even be trivial for them to DOS the
idmap system. I'm not going to give you a recipe, but if you think for
more than a minute or two you'll see lots of possibilities.

The fact is that these DOS attacks have not eventuated, mostly because
DOS attacks by authenticated users are boring. Still worth avoiding if
the cost is not too high, but not worth halting development over.

Unauthenticated remote DOS attacks are interesting, as they can be
launched by people remotely against servers, and can be payloads in
worms and other nasties. The foreign SID attack only makes sense as an
authenticated DOS, so it is not a reason to panic.

 > I know that perfectly. Still you can't really have an ACL mapping
 > working perfectly if you don't know what a SID is (exp if there are DENY
 > ACEs involved).

yes, it can work perfectly for ACEs! The dual ACE schema for working
with foreign SIDs gives perfect semantics with respect to any access
control query you throw at the ACL. It doesn't fix all the other
differences between the different ACL types, but it does completely
fix the behaviour with respect to SIDs of unknown 'sex'. Yes, it works
for DENY ACEs.

 > The problem I put on the table is: how do you avoid depletion of the
 > UID/GID space by malicious users?

right now, if you have a malicious user on any unix system you are
screwed. You are even more screwed if you run Samba or any other
complex networking service. Despite this fact, the world has not come
to an end :-)

I do have some longer term approaches I am looking at to defeat DOS
attacks on Samba, but they are very much long term approaches. Lets
not get hung up on one DOS vector now and shut out a solution to a
real problem for the sake of an imagined one.

 > That's why Samba 3 by default deny any mapping for unknown SIDs, and
 > this should not be changed until we solve the little nasty detail of the
 > DoS.

if that's the reason foreign SIDs aren't allowed then its a very bad
reason :)

Cheers, Tridge