[SSSD] [PATCHES] nss: check for Well-Known SIDs in SID based requests

Sumit Bose sbose at redhat.com
Mon Nov 11 21:03:11 UTC 2013


On Mon, Nov 11, 2013 at 10:41:46AM -0500, Simo Sorce wrote:
> On Mon, 2013-11-11 at 15:01 +0100, Sumit Bose wrote:
> > Hi,
> > 
> > with the patch set SSSD can resolve so called Well-Known SID, i.e. SIDs
> > with a special, hard-coded meaning.
> > 
> > Currently a man page entry for this feature is missing. I plan to add a
> > common section the sssd-ad and sssd-ipa man pages and a reference to
> > this section in the sssd.conf man page. The man reason to document it is
> > the introduction of reserved domain and user names. With the current
> > patches the reserved domain names are 'NT AUTHORITY' and 'BUILTIN'. The
> > reserved user names are 'NULL SID', 'Everyone', 'LOCAL', 'CONSOLE
> > LOGON', 'CREATOR OWNER', 'CREATOR GROUP', 'CREATOR OWNER SERVER',
> > 'CREATOR GROUP SERVER' and 'OWNER RIGHTS'. The tries to mimic the
> > behaviour of Samba and AD which return a domain or authority name for
> > S-1-5-[0-20] and S-1-5-32-* SIDs but none for S-1-[0-3] SIDs. For the
> > latter it would be possible to add domain/authority names (Null, World,
> > Local, Creator Authority). The leaves us with no reserved user names but
> > more reserved domain names. Any opinions what would be the better
> > approach?
> 
> Why should we reserve these names ?
> These SID are never used for actual users anyway, so I do not understand
> why would you care about their names ?
> How would you create a collision ?

The main purpose is to resolve the SIDs for [gs]etcifsacl. Currently the
output for getcifsacl with SSSD looks like:

REVISION:0x1
CONTROL:0x8404
OWNER:S-1-5-32-544
GROUP:domain users at ad18.ipa18.devel
ACL:posix_test_group at ad18.ipa18.devel:ALLOWED/0x0/FULL
ACL:S-1-2-1:ALLOWED/0x0/READ
ACL:S-1-5-32-556:ALLOWED/0x0/READ
ACL:S-1-5-18:ALLOWED/I/FULL
ACL:S-1-5-32-544:ALLOWED/I/FULL
ACL:administrator at ad18.ipa18.devel:ALLOWED/I/FULL

the well-Known SIDs are not resolved. With the patches it looks like:

REVISION:0x1
CONTROL:0x8404
OWNER:Administrators at BUILTIN
GROUP:domain users at ad18.ipa18.devel
ACL:posix_test_group at ad18.ipa18.devel:ALLOWED/0x0/FULL
ACL:CONSOLE LOGON:ALLOWED/0x0/READ
ACL:Network Configuration Operators at BUILTIN:ALLOWED/0x0/READ
ACL:SYSTEM at NT AUTHORITY:ALLOWED/I/FULL
ACL:Administrators at BUILTIN:ALLOWED/I/FULL
ACL:administrator at ad18.ipa18.devel:ALLOWED/I/FULL

Everything is resolved. Maybe I've gone a little bit to far becasuse I
just realized that winbind only resolves the BUILTIN SIDs:

REVISION:0x1
CONTROL:0x8404
OWNER:BUILTIN\Administrators
GROUP:domain users at ad18.ipa18.devel
ACL:posix_test_group at ad18.ipa18.devel:ALLOWED/0x0/FULL
ACL:S-1-2-1:ALLOWED/0x0/READ
ACL:BUILTIN\Network Configuration Operators:ALLOWED/0x0/READ
ACL:S-1-5-18:ALLOWED/I/FULL
ACL:BUILTIN\Administrators:ALLOWED/I/FULL
ACL:administrator at ad18.ipa18.devel:ALLOWED/I/FULL

setcifsacl can use the names instead of the SIDs to modify the ACLs,
hence it is useful to support the name-to-SID translation as well.  A
collision might be possible if for some reason a called e.g. 'CONSOLE
LOGIN' is created. In this case this user is only accessible by its
fully qualified name.

bye,
Sumit

> 
> > A second question is about translation. At least some of the names for
> > the Well-Knowns SIDs are translated in localized version of Windows.
> > Shall we do the same? If yes, is it possible to mark the strings  so
> > that the translators see that not a random translation is expected but
> > only the value Windows used in the corresponding localized version?
> 
> I do not think we want to follow windows for these special names for
> now, as then you would need also an option that configures what is the
> 'language' used by SSSD. Sure you could pick it up from the locale,
> but ... meh, translating names sucks, and makes understanding logs more
> difficult if names end up there.
> Also these names are never (or shouldn't) returned by SSSD anyways, so
> again why do we care for translations ?
> 
> Simo.
> 
> -- 
> Simo Sorce * Red Hat, Inc * New York
> 
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel



More information about the sssd-devel mailing list