#1472 PR `merged`: Improved overhauled 900_clone_users_and_groups.sh¶

Labels: enhancement, cleanup, fixed / solved / done

jsmeix opened issue at 2017-09-05 11:53:¶

Some minor improvements of https://github.com/rear/rear/pull/1471
but still kept the behaviour of how it worked before
https://github.com/rear/rear/pull/1471
i.e. CLONE_ALL_USERS_GROUPS
replaces the CLONE_USERS and CLONE_GROUPS

If the behaviour of how it works should be changed
a separated issue or pull request is needed.
Personally I do not intend to change the behaviour
because it seems to work o.k. as is (no user complaints).

jsmeix commented at 2017-09-06 11:59:¶

I further enhanced and improved 900_clone_users_and_groups.sh
so that it can now also copy all via 'getent' available users and groups
and described that in default.conf
but it is currently not yet tested.

@N3WWN
I would very much appreciate it if you coud test if my current
rescue/default/900_clone_users_and_groups.sh
works for you or at least have a look at the code
if you see errors therein by plain looking at the code.

jsmeix commented at 2017-09-06 12:10:¶

There is really no reason to not always extend the CLONE_USERS
and CLONE_GROUPS arrays because if that is not wanted
the user can simply specify empty CLONE_USERS and/or
CLONE_GROUPS arrays.

jsmeix commented at 2017-09-06 12:36:¶

@schlomo
note that even if "getent passwd" or "getent group"
does not list all users or groups (e.g. in larger organizations),
at least for a specific user or group "getent passwd $user"
and "getent group $group" must work because
otherwise that $user and/or $group is skipped
and must be skipped because then there is no
passwd entry or no group entry that could be copied.

schlomo commented at 2017-09-06 13:15:¶

@jsmeix thanks a lot, this is exactly what I meant. And yes, of course getent for individual items always works.

jsmeix commented at 2017-09-06 13:22:¶

@schlomo
by the way do you perhaps know if in default.conf

CLONE_GROUPS=( group ... )

is a typo or does a group named 'group' really exist
on some systems or whatever the reason is
for that default cloned group named 'group'?
Nothing goes wrong because of that - it lonly looks strange.

schlomo commented at 2017-09-06 13:23:¶

@jsmeix I think that this is a mistake. The array should be initialized to empty.

jsmeix commented at 2017-09-06 13:34:¶

According to what

git log -p --follow usr/share/rear/conf/default.conf

shows there are reasons why CLONE_GROUPS is not empty
by default so that I will not change the default to avoid
unexpected regressions (again: non-existent groups
do not matter because they are simply skipped).

That 'git log' shows that the group named 'group' was added
via the huge "Integrated P2V patch from Heinlein Support"
https://github.com/rear/rear/commits/844d50b75ac4b7722f4fee7a5ee3350b93f3adb7
via

-CLONE_GROUPS=()
+CLONE_GROUPS=(group disk cdrom floppy tape audio video lp tty dialout kmem uucp )

but I cannot find the actual reason for it.

jsmeix commented at 2017-09-06 14:13:¶

Because it works for me I "just merge" it now.
Of course if there are bugs I will fix them
as far as I can reproduce them or when the fix is obvious.

N3WWN commented at 2017-09-06 15:00:¶

@jsmeix

I would very much appreciate it if you coud test if my current
rescue/default/900_clone_users_and_groups.sh
works for you or at least have a look at the code
if you see errors therein by plain looking at the code.

Testing it now... with both YUM and YUM+backup

jsmeix commented at 2017-09-08 14:00:¶

Only FYI
a possible future further enhancement:

Because CLONE_USERS and CLONE_GROUPS are arrays
I assume it is easy to further enhance it so that
also complete /etc/passwd and /etc/group entries
could be specified if needed by the user
e.g. to even create new users and groups
in the ReaR recovery system e.g. like:

CLONE_USERS=( ... 'jnd:x:123:56:John Doe:/home/jnd:/bin/bash' 'jed:x:124:56:Jane Doe:/home/jed:/bin/bash' ...  )
CLONE_GROUPS=( ... 'does:x:56:jnd,jed' ... )

plus a test in 900_clone_users_and_groups.sh
if an array element is of the form '^[[:alnum:]_]*:'
to detect this case.

N3WWN commented at 2017-09-08 14:43:¶

@jsmeix

I've been testing the new rescue/default/900_clone_users_and_groups.sh, and it doesn't copy over the passwords for the users. I'm not sure that's an issue since this user/group cloning isn't meant to fully populate the accounts on the rescue or target systems.

The old version didn't either... only my update to it did... so this may be expected behavior at this time.

Otherwise, it seems to work just fine.

I'll restore full account cloning from source through to the target system via RECREATE_USERS_GROUPS / 395_recreate_users_and_groups.sh as discussed in #1464

jsmeix commented at 2017-09-08 15:07:¶

Regarding "copy passwords":
In general the ReaR recovery system is intended
to not contain possibly private or confidential data
so that in general no files like /etc/shadow will be copied
from the original system into the recovery system.
I.e. it is the intended behaviour to not have /etc/shadow
in the recovery system.
For ReaR only the backup needs to be protected
against unwanted access but the recovery system ISO image
should be more or less considered to be "world readable".
For other examples cf.
https://github.com/rear/rear/pull/1267#issuecomment-291836695
and
https://github.com/rear/rear/issues/1444#issuecomment-324073954
and subsequent comments there.

N3WWN commented at 2017-09-08 16:25:¶

Interesting... thanks for the education 😁

I'll keep this in mind going forward.

jsmeix commented at 2017-09-11 08:38:¶

@N3WWN
I forgot to tell about the reason behind why the recovery system
ISO image should not contain private or confidential data
(at least not unless the user explicitly configured something):
As far as I remember the reason behind is that one can burn
the recovery system ISO image onto a CD or DVD and then
one can take that recovery system medium anywhere without
the need to protect it (e.g. against it gets lost).
E.g. the admin could misuse a ReaR recovery system CD
after work as beer coaster in the next pub and he could
even forget it there after his Nth beer but still sleep well ;-)

Only as a proposal this could mean that e.g. a plain
RECREATE_USERS_GROUPS="yes"
should probably not also copy /etc/shadow by default into the
ReaR recovery system while e.g. something explicit like
RECREATE_USERS_GROUPS=( "yes" "passwords" )
could do that (provided what that means is explicitly
described in default.conf).

In particular when one has both the ReaR recovery system
plus the backup in the ISO, then it is clear that such an ISO
usually needs to be protected against unwanted access.
Accordingly in this case having /etc/shadow also in the ReaR
recovery system won't make things less secure because
usually /etc/shadow is in the backup anyway.
Except one uses backup encryption (see the
BACKUP_PROG_CRYPT_* BORGBACKUP_ENC_TYPE
and other variables in default.conf about encryption),
then /etc/shadow also in the ReaR recovery system
does make things less secure.

schlomo commented at 2017-09-11 08:46:¶

@jsmeix thanks for reminding us about the core beliefs of ReaR, this is important to keep in mind.

Before this thread runs off, what would be the purpose of cloning /etc/shadow into the rescue system? That would IMHO only be required if all those users should be able to log in via password which I find very strange.

I'd therefore suggest that we abandon the thoughts of including the /etc/shadow in the rescue system.

If the goal is to recover the user accounts in the target system then we should use the backup system (whatever that is) to transport that information.

The core and basic design principle for ReaR looks like this:

The rescue system contains metadata but not data. That means that it contains everything required to recreate the target system but nothing that goes into the target system. Therefore the rescue media is not a secret.
The backup system or tool contains all the data that goes into the target system and therefore it also contains the secrets of the target system and must be protected accordingly.

With regard to accounts I would say that passwd and group can still be considered metadata but shadow (passwords) are most definitively data.

jsmeix commented at 2017-09-15 10:07:¶

@schlomo
I fully agree with your reasoning.

I think @N3WWN does not copy the whole users and groups
into the recovery system only as a "transport" medium to get
them back on the recreated target system.

I think @N3WWN needs to copy the whole users and groups
into the recovery system to have them there while 'tar'
restores files into the target system and to do that for files with
special users and groups those users and groups must exist
with the right UID and GID numbers. Otherwise 'tar' could
restore files with wrong user/group/UID/GID, cf.
https://github.com/rear/rear/pull/1464#issuecomment-327287675

But I do not yet understand why also /etc/shadow
is copied into the recovery system.

I guess @N3WWN has already told us somewhere about
why also /etc/shadow is copied into the recovery system
but I don't remember (sorry @N3WWN for my lossy mind).

Perhaps for /etc/shadow @N3WWN copies it into the
recovery system only as a "transport" medium to get
it back on the recreated target system?

[Export of Github issue for rear/rear.]

#1472 PR merged: Improved overhauled 900_clone_users_and_groups.sh¶