Snapshots are not typed, and no check is done when restoring
Snapshots are not typed, and no check is done when restoring
Description
FD cannot know which objectType was a snapshot of, so when restoring the snapshot it just insert the LDIF saved without performing any check or processing.
FusionDirectory Version
1.2
Steps to Reproduce
- Snapshot a user
- Delete it
- Create a user with the same uid ("Login") elsewhere
- Restore the snapshot
Expected behavior:
The restore should fail in some way because uid is a unique field.
Actual behavior:
The snapshot is restored with no error and you get a duplicated uid
Additional Information
One possible solution:
- Store the objectType along with the snapshot
- Open the snapshoted LDIF through the stored objectType
- Save the opened object unless there are errors
(This is a bit similar to the process used when copy/pasting entries)
Related to fd-plugins#5631 (closed)
Activity
mentioned in issue fd-plugins#5631 (closed)
By Côme Chilliet on 2017-10-16T13:21:59 (imported from GitLab)
added PJ1802-0188 label
By bmortier on 2018-04-05T09:00:33 (imported from GitLab)
Storing object types is easy but opening an object from LDIF data is proving quite difficult. Maybe we should fall back to inserting the LDIF and opening/saving it afterwards to trigger validation errors.
It’s not clear what is expected from snapshots. I think snapshotting a user, deleting it and restoring it will lose its groups with current code, since it only restores the user LDAP node.
By Côme Chilliet on 2019-06-04T15:35:40 (imported from GitLab)
mentioned in commit 356b55b0
By Côme Chilliet on 2019-06-05T09:08:25 (imported from GitLab)
mentioned in commit b6468a56
By Côme Chilliet on 2019-06-05T15:39:35 (imported from GitLab)
Needs heavy testing
By Côme Chilliet on 2019-06-17T14:20:10 (imported from GitLab)
Edited by bmortieradded To Be Tested label
removed Bugs label
added fusiondirectory-core label
assigned to @jswaelens and unassigned @MCMic
By bmortier on 2019-06-06T19:44:05 (imported from GitLab)
When I click on "restore snapshot" in the action menu I see this error
Fatal error: Uncaught TypeError: Argument 4 passed to SnapshotRestoreDialog::__construct() must be of the type string, array given, called in /usr/share/fusiondirectory/include/management/class_management.inc on line 1097 and defined in /usr/share/fusiondirectory/include/management/snapshot/class_SnapshotRestoreDialog.inc:63 Stack trace: #0 /usr/share/fusiondirectory/include/management/class_management.inc(1097): SnapshotRestoreDialog->__construct('dc=nodomain', Object(userManagement), true, Array) #1 /usr/share/fusiondirectory/include/management/actions/class_Action.inc(170): management->restoreSnapshotDialog(Array) #2 /usr/share/fusiondirectory/include/management/class_management.inc(404): Action->execute(Object(userManagement), Array) #3 /usr/share/fusiondirectory/include/management/class_management.inc(443): management->handleAction(Array) #4 /usr/share/fusiondirectory/include/management/class_management.inc(1266): management->execute() #5 /usr/share/fusiondirectory/include/class_pluglist.inc(564): management::mainInc in /usr/share/fusiondirectory/include/management/snapshot/class_SnapshotRestoreDialog.inc on line 63By Jonathan Swaelens on 2019-06-18T09:51:26 (imported from GitLab)
removed To Be Tested label
assigned to @MCMic and unassigned @jswaelens
By Jonathan Swaelens on 2019-06-18T09:51:27 (imported from GitLab)
mentioned in commit 15431dc9
By Côme Chilliet on 2019-06-18T13:36:17 (imported from GitLab)
added To Be Tested label
assigned to @jswaelens and unassigned @MCMic
By Côme Chilliet on 2019-06-18T14:13:52 (imported from GitLab)
It restore the snapshot correctly but it not send me to the edit page (same if my uid already exist)
The snapshot dump is the following
dn: gosaSnapshotTimestamp=1560935309-050435100,ou=people,ou=snapshots,dc=nodom ain objectClass: top objectClass: gosaSnapshotObject gosaSnapshotData:: eJxtTssOgjAQvPcr+AAvaEyUhJOAhoSK4iMcK7vBCnRJC2L8elHwYrxMZnY nMwPKsVoJbmtQT6h1a6S6xAlkriKgSkjF6HLDrFmVwhjHkgqbrc5j1IZ+XqRzoeRTNJKUKP856uGW vTv7vg8wMyqWyzsqLiocdT/ry3qI+4SONDiOhTY/JH6wPHl8f/bCRzJdzKKKN5F3DXETrI9F+sRin oIdddyf78AnlwGaTMv6PW5IBcZe3UlZ4w== gosaSnapshotDN: uid=user,ou=people,dc=nodomain description: 2 fdSnapshotObjectType: USER gosaSnapshotTimestamp: 1560935309-050435100By Jonathan Swaelens on 2019-06-19T09:12:11 (imported from GitLab)
removed To Be Tested label
assigned to @MCMic and unassigned @jswaelens
By Jonathan Swaelens on 2019-06-19T09:12:12 (imported from GitLab)
FD does not signal errors on disabled fields, because the user would not be able to fix them.
This is a problem here, because the most common collisions on snapshot restore are uid and uidNumber, which are disabled (completely for uid, and activatble for uidNumber). We may add a check for uidNumber to signal the problem and force the user to change it if possible. But for uid it’s always been disabled in FD so I’m not sure how to make it editable in these circumstances. Maybe we should still signal the problem somehow?
By Côme Chilliet on 2019-06-19T15:08:18 (imported from GitLab)
assigned to @bmortier and unassigned @MCMic
By bmortier on 2019-06-20T15:57:54 (imported from GitLab)
hello @MCMic,
- uid should be unique and never changed as it is from the start.
- uidNumber should not be changed either because file system/nfs and lots of other stuff will depend on this.
so we should signal the problem but that's all
Cheers
By bmortier on 2019-08-07T12:35:43 (imported from GitLab)
added Fixed label
