firewalldb: handle deleted sessions in priv pair mig

If the user has deleted their session.db file, but kept their
rules.db file, there can exist privacy mapper pairs that point to a now
deleted session ID. Such pairs should be ignored during the migration,
as they are cannot be used anymore.

This commit updates the migration to handle this case.

Author: ViktorT-11

firewalldb/sql_migration.go

@@ -617,8 +617,19 @@ func collectPrivacyPairs(kvStore *bbolt.DB,
 
 			sess, ok := sessMap[groupAlias]
 			if !ok {
-				return fmt.Errorf("session with group id %x "+
-					"not found in sql db", groupId)
+				// If we can't find the session group in the SQL
+				// db, that indicates that the session was never
+				// migrated from KVDB. This likely means that
+				// the user deleted their session.db file, but
+				// kept the rules.db file. As the privacy pairs
+				// are useless when the session no longer
+				// exists, we can just skip the migration of the
+				// privacy pairs for this group.
+				log.Warnf("Skipping migration of privacy "+
+					"pairs for session group %x, as the "+
+					"session group was not found", groupId)
+
+				return nil
 			}
 
 			if !sess.GroupID.Valid {

firewalldb/sql_migration_test.go

@@ -458,6 +458,14 @@ func TestFirewallDBMigration(t *testing.T) {
 			name:       "multiple sessions and privacy pairs",
 			populateDB: multipleSessionsAndPrivacyPairs,
 		},
+		{
+			name:       "deleted session with privacy pair",
+			populateDB: deletedSessionWithPrivPair,
+		},
+		{
+			name:       "deleted and existing sessions with privacy pairs",
+			populateDB: deletedAndExistingSessionsWithPrivPairs,
+		},
 		{
 			name:       "random privacy pairs",
 			populateDB: randomPrivacyPairs,
@@ -1059,6 +1067,53 @@ func oneSessionAndPrivPair(t *testing.T, ctx context.Context,
 	return createPrivacyPairs(t, ctx, boltDB, sessionStore, 1, 1)
 }
 
+// deletedSessionWithPrivPair inserts 1 session with a linked 1 privacy pair
+// into the boltDB, and then deletes the session from the sessions store, to
+// simulate the case where a session has been deleted, but the privacy pairs
+// still exist. This can happen if the user deletes their session db but not
+// their firewall db.
+func deletedSessionWithPrivPair(t *testing.T, ctx context.Context,
+	boltDB *BoltDB, sessionStore session.Store, _ accounts.Store,
+	_ *rootKeyMockStore) *expectedResult {
+
+	_ = createPrivacyPairs(t, ctx, boltDB, sessionStore, 1, 1)
+
+	// Now we delete the session that the privacy pair was linked to.
+	err := sessionStore.DeleteReservedSessions(ctx)
+	require.NoError(t, err)
+
+	return &expectedResult{
+		kvEntries: []*kvEntry{},
+		// Since the session the privacy pair was linked to has been
+		// deleted, we expect no privacy pairs to be migrated.
+		privPairs: make(privacyPairs),
+		actions:   []*Action{},
+	}
+}
+
+// deletedAndExistingSessionsWithPrivPairs generates 2 different privacy pairs,
+// each linked to a different sessions. However, one of the sessions is deleted
+// prior to the migration, to test that only one of the privacy pairs should be
+// migrated, while the other one should be ignored since its session has been
+// deleted.
+func deletedAndExistingSessionsWithPrivPairs(t *testing.T, ctx context.Context,
+	boltDB *BoltDB, sessionStore session.Store, _ accounts.Store,
+	_ *rootKeyMockStore) *expectedResult {
+
+	// First generate one privacy pair linked to a session that will be
+	// deleted.
+	_ = createPrivacyPairs(t, ctx, boltDB, sessionStore, 1, 1)
+
+	// Delete the linked session.
+	err := sessionStore.DeleteReservedSessions(ctx)
+	require.NoError(t, err)
+
+	// Now generate another privacy pair linked to a session that won't be
+	// deleted prior to the migration. Therefore, this privacy pair should
+	// be migrated.
+	return createPrivacyPairs(t, ctx, boltDB, sessionStore, 1, 1)
+}
+
 // oneSessionsMultiplePrivPairs inserts 1 session with 10 privacy pairs into the
 // boltDB.
 func oneSessionsMultiplePrivPairs(t *testing.T, ctx context.Context,