moonfire-nvr/server/db/proto/schema.proto

// This file is part of Moonfire NVR, a security camera network video recorder.
// Copyright (C) 2018 The Moonfire NVR Authors
//
// This program is free software: you can redistribute it and/or modify
// it under the terms of the GNU General Public License as published by
// the Free Software Foundation, either version 3 of the License, or
// (at your option) any later version.
//
// In addition, as a special exception, the copyright holders give
// permission to link the code of portions of this program with the
// OpenSSL library under certain conditions as described in each
// individual source file, and distribute linked combinations including
// the two.
//
// You must obey the GNU General Public License in all respects for all
// of the code used other than OpenSSL. If you modify file(s) with this
// exception, you may extend this exception to your version of the
// file(s), but you are not obligated to do so. If you do not wish to do
// so, delete this exception statement from your version. If you delete
// this exception statement from all source files in the program, then
// also delete it here.
//
// This program is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
// GNU General Public License for more details.
//
// You should have received a copy of the GNU General Public License
// along with this program.  If not, see <http://www.gnu.org/licenses/>.

syntax = "proto3";

// Metadata stored in sample file dirs as "<dir>/meta". This is checked
// against the metadata stored within the database to detect inconsistencies
// between the directory and database, such as those described in
// design/schema.md.
//
// As of schema version 4, the overall file format is as follows: a
// varint-encoded length, followed by a serialized DirMeta message, followed
// by NUL bytes padding to a total length of 512 bytes. This message never
// exceeds that length.
//
// The goal of this format is to allow atomically rewriting a meta file
// in-place. I hope that on modern OSs and hardware, a single-sector
// rewrite is atomic, though POSIX frustratingly doesn't seem to guarantee
// this. There's some discussion of that here:
// <https://stackoverflow.com/a/2068608/23584>. At worst, there's a short
// window during which the meta file can be corrupted. As the file's purpose
// is to check for inconsistencies, it can be reconstructed if you assume no
// inconsistency exists.
//
// Schema version 3 wrote a serialized DirMeta message with no length or
// padding, and renamed new meta files over the top of old. This scheme
// requires extra space while opening the directory. If the filesystem is
// completely full, it requires freeing space manually, an undocumented and
// error-prone administrator procedure.
message DirMeta {
  // A uuid associated with the database, in binary form. dir_uuid is strictly
  // more powerful, but it improves diagnostics to know if the directory
  // belongs to the expected database at all or not.
  bytes db_uuid = 1;

  // A uuid associated with the directory itself.
  bytes dir_uuid = 2;

  // Corresponds to an entry in the `open` database table.
  message Open {
    uint32 id = 1;
    bytes uuid = 2;
  }

  // The last open that was known to be recorded in the database as completed.
  // Absent if this has never happened. Note this can backtrack in exactly one
  // scenario: when deleting the directory, after all associated files have
  // been deleted, last_complete_open can be moved to in_progress_open.
  Open last_complete_open = 3;

  // The last run which is in progress, if different from last_complete_open.
  // This may or may not have been recorded in the database, but it's
  // guaranteed that no data has yet been written by this open.
  Open in_progress_open = 4;
}

// Permissions to perform actions, currently all simple bools.
//
// These indicate actions which may be unnecessary in some contexts. Some
// basic access - like listing the cameras - is currently always allowed.
// See design/api.md for a description of what requires these permissions.
//
// These are used in a few contexts:
// * a session - affects what can be done when using that session to
//   authenticate.
// * a user - when a new session is created, it inherits these permissions.
// * on the commandline - to specify what permissions are available for
//   unauthenticated access.
message Permissions {
  bool view_video = 1;
  bool read_camera_configs = 2;

  bool update_signals = 3;
}