Fwd: Re: s4: new classicupgrade and uids

Sergey Urushkin urushkin at telros.ru
Thu Aug 9 00:25:40 MDT 2012


08.08.2012 15:29, Andrew Bartlett пишет:
> On Wed, 2012-08-08 at 15:21 +0400, Sergey Urushkin wrote:
>> 08.08.2012 12:55, Andrew Bartlett пишет:
>>
>>> On Wed, 2012-08-08 at 11:01 +0400, Sergey Urushkin wrote:
>>>> Hi.
>>>> Some time ago I sent the patch to the list, but didn't get answer. For
>>>> better readability it's attached again.
>>>> The problem with it now is that it may set administrator uid to non-zero
>>>> value (what will break GP editing, until appropriate posix acls is set.
>>>> As a workaround - chown -R administrator path/to/sysvol). It may need
>>>> additional warning message.
>>> My thoughts are that I don't like the upgrade handling any of the well
>>> known users, except perhaps to assign a UID.  Even then, things like
>>> administrator UID should be connected via the provision() stage.
>> Then, may be we should add some default uid/gid attributes to
>> wellknown users/groups on the provision stage (if --use-rfc2307 is
>> used add them to the directory too). That would also be a step to
>> provision default posix acls for sysvol. Here is the list which I feel
>> needed and suggested values.
>>
>> name : sid : uid/gid
>> ---------------------------------
>> Administrators    :    S-1-5-32-544    :    300544                -
>> should to be synced on all dcs (it's a part of default ms's sysvol
>> permissions)
>> Server Operators    :    S-1-5-32-549    :    300549            - the
>> same
>> Authenticated Users    :    S-1-5-11    :    300011              - the
>> same
>> Local System    :    S-1-5-18    :    300018/300018             - the
>> same
>>
>> Administrator    :    S-1-5-21domain-500    :    0/0
>> Guest    :    S-1-5-21domain-501    :    nobody's uid/nobody's gid
>> Anonymous    :    S-1-5-7    :    nobody's gid
>>
>> What do you think?
> I don't mind assigning a UID in the directory based on the imported
> values to well known users, but I'm just saying we need to be careful
> about actually 'importing' the user.
If you are suggesting importing only uid and gid for wellknown accounts,
then I'll change the patch such way.
But could you explain why we need to import it via provision()? For
example, "domain admins" is a wellknown account too, but we don't import
it via provision().
Another question is what I wrote previously: for >1 DC's domains we need
to write at least several account's uid/gid to the ldap while
provisioning, to have acls synced. So, some uid/gid initialization is
needed for provision anyway. And in the case of classicupgrade
s3-existed account uids would be overwritten. Doesn't it look reasonable?
>>>> Also, I have to say that "if entry['rid'] < 1000:" check gives an error
>>>> at the "adding users to groups" stage (nonexisting user). Ways to solve it:
>>>>  1. Stop provision with error if such accounts exist (think it's the best)
>>>>  2. Add some workaround to the function that lists members
>>>>  3. Remove this check.
>>> I'm not entirely sure what you mean here.  I guess we do need to upgrade
>>> groups of any well known users we find?
>>>
>> If group contains user with rid < 1000 (skipped), then
>> add_users_to_group ends with error (because this user hasn't been
>> actually imported), and upgrading fails.
>> So, if there are 1000 users, we have to wait for a really long time
>> (while all users are being imported) to just see an error at the end.
>> I think we should give an error immediately, or test somehow for user
>> existence in s4 db before trying to add it to some group.   
> What users are you importing with a sid below 1000 that Samba4 doesn't
> already define?
>
I haven't yet met such users, I've got this issue while testing
suggested patch (I changed the sid manually for one of the users). I'm
just trying to say if someone's s3db contains such user (I guess some
do), we'll need to do something with it, the more so because we already
have this check.

-- 
Best regards,
Sergey Urushkin



More information about the samba-technical mailing list