KCPWiki - User contributions [en]

Media Repository Administration

2025-08-29T22:46:41Z

KarlPinc: /* User and group management tools */

== Introduction ==

The KCP media repository controls access using the standard Unix
[https://www.gnu.org/software/coreutils/manual/html_node/Changing-file-attributes.html ownership] and
[https://www.gnu.org/software/coreutils/manual/html_node/File-permissions.html permission] system.
Specifically, it uses the [https://flylib.com/books/en/4.150.1.60/1/ User-Private-Group] (UPG) idiom.
This scheme works by associating a group with a directory and giving users, users that are allowed to make changes, membership in the group.
In this document such groups are called "media groups".

If you are in a media group you have read/write access to the group's media files.
Otherwise, you have read access -- or no access.

This is a simple approach, and has some limitations.

* Any given file can be in only one directory and is associated with only a single group. Categorizing a file as modifiable by multiple groups is not possible.

* Files and directories have an owner as well as a group. Typically the owner has read/write permissions. When a file or directory's owner is not a member of the file or directory's group, looking solely at group membership does not reflect the owner's permissions.

* The UPG idiom assumes that files remain in the directories in which they were initially put, or a sub-directory. It works because new files are given the group of the directory in which they are placed. Moving files between directories that belong to different groups requires that the file's groups be manually changed to reflect the group of the new containing directory. At least this is required if directories are assumed to control permission, so that who has access to what can be readily determined by where a file is placed in the directory hierarchy. This problem is mitigated with the use of a bespoke auditing tool, kcpm-audit.

* Membership in a group gives read/write permissions but says nothing about who can read but not change a file. To grant or deny read-only permission a different mechanism is used, granting or denying access to "other", anybody who's not either the file's owner or a group member. So determining who has read-only access is different from, and more complicated than determining who has read-write access. To obtain any kind of access to a file a user must have at least read permissions on the directory containing the file, and all of the parent directories.

Although standard Unix command line tools are available for use and
can do the job, to simplify and standardize a number of bespoke command
line tools are made available to do things like create media user
accounts, create permission controlled media directories, and other
management tasks.

The system has some naming conventions which aim to simplify
management and system use. These are enforced when using the bespoke
management command line tools. The conventions are:

* Directories that introduce permission restrictions have names that end in either "_public" or "_private". The ones ending in "_public" contain files that are readable by anyone with a media login. The ones ending in "_private" are readable only by media logins who are members of the directory's group.

* The groups that categorize access to media files, in which media users are made members, begin with "m-".

=== About alternative permission control mechanisms ===

[https://manpages.debian.org/bookworm/acl/acl.5.en.html ACL]s are a
permission system that can be used in conjunction with the traditional
Unix permission system. ACLs provide fine-grained control over who
has permission to do exactly what to each file. But ACL use is
non-obvious, and ACL permissions are unlikely to be visible in
off-the-shelf graphical remote access mechanisms which use SFTP.
So while ACLs are available their use is not recommended.

== The Groups Built-In to the System ==

The media repository< system is constructed of 2 core groups.
These are the groups which the operating system is aware of and which provide it control.

;sftp-only
: Members of this group are "media logins". A media login is a regular Unix login that is in the <code>sftp-only</code> group. These logins cannot reach the Unix shell, which processes Unix commands.

;media-admin
: Members of this group have permission to use the bespoke programs which require elevated system-level privileges, like create new logins or groups.

== Working from the Unix command line ==

=== File Locations and Disk Space Management ===

All media files are located in the <code>/srv/media/</code> directory.

The amount of available space, and space already used, can be seen
with:

[https://www.gnu.org/software/coreutils/manual/html_node/df-invocation.html df] -h /srv/media

=== Using the Unix Command Line ===

All the command line tools take a <code>--help</code> argument, which
causes the command to display a brief summary of its functionality and
arguments. The bespoke command line tools generally have no other
documentation. You will need to execute them with the
<code>--help</code> argument to determine their usage and arguments.
Documentation to the standard Unix command line tools are linked
herein.

=== Permission Errors ===

Some of the standard Unix commands, like <code>chown</code>, which
changes file or directory ownership, requires special permission to
run. If a "permission denied" error is received, try running the
command with the word <code>sudo</code> placed in front.

When specifying a file or directory, <code>sudo</code> will require
the fully qualified path -- a pathname that starts with
<code>/srv/media/</code> and lists all intermediate directories.

=== Difficulties Involving Adding Groups ===

When a user is added to or removed from a group, the change does not take effect
until after the user logs in.

This matters, among other times, when adding your login to a group. Your login normally does not have permission to work with a group when your login is not a group member. After adding yourself to a group it is usually best to login again to gain immediate access to the group.

== User and group management tools ==

;kcpm-adduser
: Creates a media user (a member of the sftp-only group), or adds any user to a media group.

;kcpm-deluser
: Deletes a media user, if the user owns no files. Or removes a media user from a media group.

;kcpm-user-list
: Lists all members of the sftp-only group, and the groups they are in.

;kcpm-group-list
: Lists all media groups, and the users they contain. Media groups are identified by a "m-" prefix.

;kcpm-addgroup
:Creates a media group.

;kcpm-delgroup
: Deletes a media group, only if there are no members, and no files in the group.

== Directory and file management tools ==

=== CAUTION ===

Do not move files between directories which are in different groups.
If you do, by a method other than <code>kcpm-mv</code>, the file's group will not
reflect the group of its containing directory. That means that when
a file is moved to a publicly readable directory it can still be
modified by the group members of the origin directory, and is not
modifiable by the group members of the containing directory.

If you do move a file, the group of the file must be changed to
match the group of its containing directory. As an alternative to
moving (renaming), copy the file and delete the original. (This
will involve downloading and re-uploading, unless you're working
from the Unix prompt.)

<code>kcpm-audit</code> can be run to report on such discrepancies, and to change
group membership of files to reflect that of their containing
directory.

Directories are rooted at a [https://www.gnu.org/software/coreutils/manual/html_node/Directory-Setuid-and-Setgid.html setgid] directory, group <code>sftp-only</code>, so all
sub-directories are setgid.

=== kcpm-mkmdir ===

Given a group and a directory name, makes a directory in the group.
The group then controls access to content added to the directory.
<code>--private</code> makes a directory with a name ending in "_private".
<code>--public</code> makes a directory with a name ending in "_public".
The *_public directory is readable by anyone with a login. The *_private
directory is readable only by members of the group.

This is a convenience utility. The <code>chgrp</code> command can be used to
change the group of a directory, and <code>chmod o-x</code> will make a
directory private. The *_public and *_private naming conventions
are recommended. They provide clear guidance as to which
directories control access.

=== kcpm-mv ===
Move or rename files or directories.
Takes care of re-assigning groups when moving files.

This is a convenience utility. The <code>chgrp -R</code> command can be used
to (recursively) change group permissions. Files should be in the
group of their containing directory, so take care using
<code>-R</code> when nested directories are in different groups.

=== kcpm-audit ===
Given a directory, recursively report on unexpected permissions structures.
* Directories named *_public that are in the group of the parent
* Directories named *_public that are private (o-x)
* Directories named *_private that are not private (o+x)
* Files that are not in the group of their parent directory
* Files or directories that are owned by a user who is not a member of the file or directory's group.

Or, changes permissions to fix all of the above.

=== [https://www.gnu.org/software/coreutils/manual/html_node/chgrp-invocation.html chgrp] (-R) ... ===

Change the group

=== [https://www.gnu.org/software/coreutils/manual/html_node/chmod-invocation.html chmod] o-x ... ===

Remove public access from a directory.

=== [https://www.gnu.org/software/coreutils/manual/html_node/chmod-invocation.html chmod] o+x ... ===

Add public access to a directory.

=== [https://www.gnu.org/software/coreutils/manual/html_node/rm-invocation.html rm] ===

Delete a file or a directory structure.

=== [https://www.gnu.org/software/coreutils/manual/html_node/rmdir-invocation.html rmdir] ===

Delete an empty directory.

=== [https://www.gnu.org/software/coreutils/manual/html_node/mkdir-invocation.html mkdir] ===

Make non-media-controlled directories

=== [https://www.gnu.org/software/findutils/manual/html_mono/find.html find] . -group name ===

Find everything belonging to a group. Find has many options, and
can even be used to execute commands on the files found. It is
useful for things like bulk changing of file ownership.

=== [https://www.gnu.org/software/coreutils/manual/html_node/ls-invocation.html ls] -lhR ===

Show everything in the file system.

== Techniques ==

Anything put in the top-level directory are read/writable to anyone
with a login.

=== Make a test login to test access ===

A test login can be created, and put into any set of groups.
This allows for testing of access, and emulating what a user who's in
the same set of groups is allowed to do.

=== Layer directories to control access ===

"Regular" directories can be used at any level to structure content.

If you have topdir_private/subdir, in respective groups topdir and
subdir, consider the content of subdir. Only topdir members have
access. Members of subdir have read/write access, and topdir members
have read-only access.

Main Page

2025-04-05T03:23:46Z

KarlPinc: /* The KCPDB -- The Kibale Chimpanzee Project DataBase */ Add various user interfaces

== The KCPDB -- The Kibale Chimpanzee Project DataBase ==
* Access the database
** Preferred interfaces
*** [https://kibale.unm.edu/programs/sql Preferred SQL interface]
*** [https://kibale.unm.edu/programs/upload Preferred upload interface]
*** [https://kibale.unm.edu/programs/logout Logout from preferred interfaces]
** Other interfaces
*** [https://kibale.unm.edu/adminer/ Adminer generic Postgres interface]
*** [https://kibale.unm.edu/pgadmin/ PgAdmin generic Postgres interface]
*** [https://kibale.unm.edu/programs/ Complete set of bespoke (PGWUI) Postgres interfaces]
* Documentation
** [[Media Archive|The Media Archive]]
* [[Administration|Administrative Tasks]]

Media Repository Administration

2025-02-08T17:57:04Z

KarlPinc: /* Working from the Unix command line */ Note group membership is not changed until login

== Introduction ==

The KCP media repository controls access using the standard Unix
[https://www.gnu.org/software/coreutils/manual/html_node/Changing-file-attributes.html ownership] and
[https://www.gnu.org/software/coreutils/manual/html_node/File-permissions.html permission] system.
Specifically, it uses the [https://flylib.com/books/en/4.150.1.60/1/ User-Private-Group] (UPG) idiom.
This scheme works by associating a group with a directory and giving users, users that are allowed to make changes, membership in the group.
In this document such groups are called "media groups".

If you are in a media group you have read/write access to the group's media files.
Otherwise, you have read access -- or no access.

This is a simple approach, and has some limitations.

* Any given file can be in only one directory and is associated with only a single group. Categorizing a file as modifiable by multiple groups is not possible.

* Files and directories have an owner as well as a group. Typically the owner has read/write permissions. When a file or directory's owner is not a member of the file or directory's group, looking solely at group membership does not reflect the owner's permissions.

* The UPG idiom assumes that files remain in the directories in which they were initially put, or a sub-directory. It works because new files are given the group of the directory in which they are placed. Moving files between directories that belong to different groups requires that the file's groups be manually changed to reflect the group of the new containing directory. At least this is required if directories are assumed to control permission, so that who has access to what can be readily determined by where a file is placed in the directory hierarchy. This problem is mitigated with the use of a bespoke auditing tool, kcpm-audit.

* Membership in a group gives read/write permissions but says nothing about who can read but not change a file. To grant or deny read-only permission a different mechanism is used, granting or denying access to "other", anybody who's not either the file's owner or a group member. So determining who has read-only access is different from, and more complicated than determining who has read-write access. To obtain any kind of access to a file a user must have at least read permissions on the directory containing the file, and all of the parent directories.

Although standard Unix command line tools are available for use and
can do the job, to simplify and standardize a number of bespoke command
line tools are made available to do things like create media user
accounts, create permission controlled media directories, and other
management tasks.

The system has some naming conventions which aim to simplify
management and system use. These are enforced when using the bespoke
management command line tools. The conventions are:

* Directories that introduce permission restrictions have names that end in either "_public" or "_private". The ones ending in "_public" contain files that are readable by anyone with a media login. The ones ending in "_private" are readable only by media logins who are members of the directory's group.

* The groups that categorize access to media files, in which media users are made members, begin with "m-".

=== About alternative permission control mechanisms ===

[https://manpages.debian.org/bookworm/acl/acl.5.en.html ACL]s are a
permission system that can be used in conjunction with the traditional
Unix permission system. ACLs provide fine-grained control over who
has permission to do exactly what to each file. But ACL use is
non-obvious, and ACL permissions are unlikely to be visible in
off-the-shelf graphical remote access mechanisms which use SFTP.
So while ACLs are available their use is not recommended.

== The Groups Built-In to the System ==

The media repository< system is constructed of 2 core groups.
These are the groups which the operating system is aware of and which provide it control.

;sftp-only
: Members of this group are "media logins". A media login is a regular Unix login that is in the <code>sftp-only</code> group. These logins cannot reach the Unix shell, which processes Unix commands.

;media-admin
: Members of this group have permission to use the bespoke programs which require elevated system-level privileges, like create new logins or groups.

== Working from the Unix command line ==

=== File Locations and Disk Space Management ===

All media files are located in the <code>/srv/media/</code> directory.

The amount of available space, and space already used, can be seen
with:

[https://www.gnu.org/software/coreutils/manual/html_node/df-invocation.html df] -h /srv/media

=== Using the Unix Command Line ===

All the command line tools take a <code>--help</code> argument, which
causes the command to display a brief summary of its functionality and
arguments. The bespoke command line tools generally have no other
documentation. You will need to execute them with the
<code>--help</code> argument to determine their usage and arguments.
Documentation to the standard Unix command line tools are linked
herein.

=== Permission Errors ===

Some of the standard Unix commands, like <code>chown</code>, which
changes file or directory ownership, requires special permission to
run. If a "permission denied" error is received, try running the
command with the word <code>sudo</code> placed in front.

When specifying a file or directory, <code>sudo</code> will require
the fully qualified path -- a pathname that starts with
<code>/srv/media/</code> and lists all intermediate directories.

=== Difficulties Involving Adding Groups ===

When a user is added to or removed from a group, the change does not take effect
until after the user logs in.

This matters, among other times, when adding your login to a group. Your login normally does not have permission to work with a group when your login is not a group member. After adding yourself to a group it is usually best to login again to gain immediate access to the group.

== User and group management tools ==

;kcpm-adduser
: Creates a media user, or adds a media user to a media group.

;kcpm-deluser
: Deletes a media user, if the user owns no files. Or removes a media user from a media group.

;kcpm-user-list
: Lists all members of the sftp-only group, and the groups they are in.

;kcpm-group-list
: Lists all media groups, and the users they contain. Media groups are identified by a "m-" prefix.

;kcpm-addgroup
:Creates a media group.

;kcpm-delgroup
: Deletes a media group, only if there are no members, and no files in the group.

== Directory and file management tools ==

=== CAUTION ===

Do not move files between directories which are in different groups.
If you do, by a method other than <code>kcpm-mv</code>, the file's group will not
reflect the group of its containing directory. That means that when
a file is moved to a publicly readable directory it can still be
modified by the group members of the origin directory, and is not
modifiable by the group members of the containing directory.

If you do move a file, the group of the file must be changed to
match the group of its containing directory. As an alternative to
moving (renaming), copy the file and delete the original. (This
will involve downloading and re-uploading, unless you're working
from the Unix prompt.)

<code>kcpm-audit</code> can be run to report on such discrepancies, and to change
group membership of files to reflect that of their containing
directory.

Directories are rooted at a [https://www.gnu.org/software/coreutils/manual/html_node/Directory-Setuid-and-Setgid.html setgid] directory, group <code>sftp-only</code>, so all
sub-directories are setgid.

=== kcpm-mkmdir ===

Given a group and a directory name, makes a directory in the group.
The group then controls access to content added to the directory.
<code>--private</code> makes a directory with a name ending in "_private".
<code>--public</code> makes a directory with a name ending in "_public".
The *_public directory is readable by anyone with a login. The *_private
directory is readable only by members of the group.

This is a convenience utility. The <code>chgrp</code> command can be used to
change the group of a directory, and <code>chmod o-x</code> will make a
directory private. The *_public and *_private naming conventions
are recommended. They provide clear guidance as to which
directories control access.

=== kcpm-mv ===
Move or rename files or directories.
Takes care of re-assigning groups when moving files.

This is a convenience utility. The <code>chgrp -R</code> command can be used
to (recursively) change group permissions. Files should be in the
group of their containing directory, so take care using
<code>-R</code> when nested directories are in different groups.

=== kcpm-audit ===
Given a directory, recursively report on unexpected permissions structures.
* Directories named *_public that are in the group of the parent
* Directories named *_public that are private (o-x)
* Directories named *_private that are not private (o+x)
* Files that are not in the group of their parent directory
* Files or directories that are owned by a user who is not a member of the file or directory's group.

Or, changes permissions to fix all of the above.

=== [https://www.gnu.org/software/coreutils/manual/html_node/chgrp-invocation.html chgrp] (-R) ... ===

Change the group

=== [https://www.gnu.org/software/coreutils/manual/html_node/chmod-invocation.html chmod] o-x ... ===

Remove public access from a directory.

=== [https://www.gnu.org/software/coreutils/manual/html_node/chmod-invocation.html chmod] o+x ... ===

Add public access to a directory.

=== [https://www.gnu.org/software/coreutils/manual/html_node/rm-invocation.html rm] ===

Delete a file or a directory structure.

=== [https://www.gnu.org/software/coreutils/manual/html_node/rmdir-invocation.html rmdir] ===

Delete an empty directory.

=== [https://www.gnu.org/software/coreutils/manual/html_node/mkdir-invocation.html mkdir] ===

Make non-media-controlled directories

=== [https://www.gnu.org/software/findutils/manual/html_mono/find.html find] . -group name ===

Find everything belonging to a group. Find has many options, and
can even be used to execute commands on the files found. It is
useful for things like bulk changing of file ownership.

=== [https://www.gnu.org/software/coreutils/manual/html_node/ls-invocation.html ls] -lhR ===

Show everything in the file system.

== Techniques ==

Anything put in the top-level directory are read/writable to anyone
with a login.

=== Make a test login to test access ===

A test login can be created, and put into any set of groups.
This allows for testing of access, and emulating what a user who's in
the same set of groups is allowed to do.

=== Layer directories to control access ===

"Regular" directories can be used at any level to structure content.

If you have topdir_private/subdir, in respective groups topdir and
subdir, consider the content of subdir. Only topdir members have
access. Members of subdir have read/write access, and topdir members
have read-only access.

Media Repository Administration

2025-02-08T17:37:10Z

KarlPinc: /* Directory and file management tools */ Clean up formatting

== Introduction ==

The KCP media repository controls access using the standard Unix
[https://www.gnu.org/software/coreutils/manual/html_node/Changing-file-attributes.html ownership] and
[https://www.gnu.org/software/coreutils/manual/html_node/File-permissions.html permission] system.
Specifically, it uses the [https://flylib.com/books/en/4.150.1.60/1/ User-Private-Group] (UPG) idiom.
This scheme works by associating a group with a directory and giving users, users that are allowed to make changes, membership in the group.
In this document such groups are called "media groups".

If you are in a media group you have read/write access to the group's media files.
Otherwise, you have read access -- or no access.

This is a simple approach, and has some limitations.

* Any given file can be in only one directory and is associated with only a single group. Categorizing a file as modifiable by multiple groups is not possible.

* Files and directories have an owner as well as a group. Typically the owner has read/write permissions. When a file or directory's owner is not a member of the file or directory's group, looking solely at group membership does not reflect the owner's permissions.

* The UPG idiom assumes that files remain in the directories in which they were initially put, or a sub-directory. It works because new files are given the group of the directory in which they are placed. Moving files between directories that belong to different groups requires that the file's groups be manually changed to reflect the group of the new containing directory. At least this is required if directories are assumed to control permission, so that who has access to what can be readily determined by where a file is placed in the directory hierarchy. This problem is mitigated with the use of a bespoke auditing tool, kcpm-audit.

* Membership in a group gives read/write permissions but says nothing about who can read but not change a file. To grant or deny read-only permission a different mechanism is used, granting or denying access to "other", anybody who's not either the file's owner or a group member. So determining who has read-only access is different from, and more complicated than determining who has read-write access. To obtain any kind of access to a file a user must have at least read permissions on the directory containing the file, and all of the parent directories.

Although standard Unix command line tools are available for use and
can do the job, to simplify and standardize a number of bespoke command
line tools are made available to do things like create media user
accounts, create permission controlled media directories, and other
management tasks.

The system has some naming conventions which aim to simplify
management and system use. These are enforced when using the bespoke
management command line tools. The conventions are:

* Directories that introduce permission restrictions have names that end in either "_public" or "_private". The ones ending in "_public" contain files that are readable by anyone with a media login. The ones ending in "_private" are readable only by media logins who are members of the directory's group.

* The groups that categorize access to media files, in which media users are made members, begin with "m-".

=== About alternative permission control mechanisms ===

[https://manpages.debian.org/bookworm/acl/acl.5.en.html ACL]s are a
permission system that can be used in conjunction with the traditional
Unix permission system. ACLs provide fine-grained control over who
has permission to do exactly what to each file. But ACL use is
non-obvious, and ACL permissions are unlikely to be visible in
off-the-shelf graphical remote access mechanisms which use SFTP.
So while ACLs are available their use is not recommended.

== The Groups Built-In to the System ==

The media repository< system is constructed of 2 core groups.
These are the groups which the operating system is aware of and which provide it control.

;sftp-only
: Members of this group are "media logins". A media login is a regular Unix login that is in the <code>sftp-only</code> group. These logins cannot reach the Unix shell, which processes Unix commands.

;media-admin
: Members of this group have permission to use the bespoke programs which require elevated system-level privileges, like create new logins or groups.

== Working from the Unix command line ==

=== File Locations and Disk Space Management ===

All media files are located in the <code>/srv/media/</code> directory.

The amount of available space, and space already used, can be seen
with:

[https://www.gnu.org/software/coreutils/manual/html_node/df-invocation.html df] -h /srv/media

=== Using the Unix Command Line ===

All the command line tools take a <code>--help</code> argument, which
causes the command to display a brief summary of its functionality and
arguments. The bespoke command line tools generally have no other
documentation. You will need to execute them with the
<code>--help</code> argument to determine their usage and arguments.
Documentation to the standard Unix command line tools are linked
herein.

=== Permission errors ===

Some of the standard Unix commands, like <code>chown</code>, which
changes file or directory ownership, requires special permission to
run. If a "permission denied" error is received, try running the
command with the word <code>sudo</code> placed in front.

When specifying a file or directory, <code>sudo</code> will require
the fully qualified path -- a pathname that starts with
<code>/srv/media/</code> and lists all intermediate directories.

== User and group management tools ==

;kcpm-adduser
: Creates a media user, or adds a media user to a media group.

;kcpm-deluser
: Deletes a media user, if the user owns no files. Or removes a media user from a media group.

;kcpm-user-list
: Lists all members of the sftp-only group, and the groups they are in.

;kcpm-group-list
: Lists all media groups, and the users they contain. Media groups are identified by a "m-" prefix.

;kcpm-addgroup
:Creates a media group.

;kcpm-delgroup
: Deletes a media group, only if there are no members, and no files in the group.

== Directory and file management tools ==

=== CAUTION ===

Do not move files between directories which are in different groups.
If you do, by a method other than <code>kcpm-mv</code>, the file's group will not
reflect the group of its containing directory. That means that when
a file is moved to a publicly readable directory it can still be
modified by the group members of the origin directory, and is not
modifiable by the group members of the containing directory.

If you do move a file, the group of the file must be changed to
match the group of its containing directory. As an alternative to
moving (renaming), copy the file and delete the original. (This
will involve downloading and re-uploading, unless you're working
from the Unix prompt.)

<code>kcpm-audit</code> can be run to report on such discrepancies, and to change
group membership of files to reflect that of their containing
directory.

Directories are rooted at a [https://www.gnu.org/software/coreutils/manual/html_node/Directory-Setuid-and-Setgid.html setgid] directory, group <code>sftp-only</code>, so all
sub-directories are setgid.

=== kcpm-mkmdir ===

Given a group and a directory name, makes a directory in the group.
The group then controls access to content added to the directory.
<code>--private</code> makes a directory with a name ending in "_private".
<code>--public</code> makes a directory with a name ending in "_public".
The *_public directory is readable by anyone with a login. The *_private
directory is readable only by members of the group.

This is a convenience utility. The <code>chgrp</code> command can be used to
change the group of a directory, and <code>chmod o-x</code> will make a
directory private. The *_public and *_private naming conventions
are recommended. They provide clear guidance as to which
directories control access.

=== kcpm-mv ===
Move or rename files or directories.
Takes care of re-assigning groups when moving files.

This is a convenience utility. The <code>chgrp -R</code> command can be used
to (recursively) change group permissions. Files should be in the
group of their containing directory, so take care using
<code>-R</code> when nested directories are in different groups.

=== kcpm-audit ===
Given a directory, recursively report on unexpected permissions structures.
* Directories named *_public that are in the group of the parent
* Directories named *_public that are private (o-x)
* Directories named *_private that are not private (o+x)
* Files that are not in the group of their parent directory
* Files or directories that are owned by a user who is not a member of the file or directory's group.

Or, changes permissions to fix all of the above.

=== [https://www.gnu.org/software/coreutils/manual/html_node/chgrp-invocation.html chgrp] (-R) ... ===

Change the group

=== [https://www.gnu.org/software/coreutils/manual/html_node/chmod-invocation.html chmod] o-x ... ===

Remove public access from a directory.

=== [https://www.gnu.org/software/coreutils/manual/html_node/chmod-invocation.html chmod] o+x ... ===

Add public access to a directory.

=== [https://www.gnu.org/software/coreutils/manual/html_node/rm-invocation.html rm] ===

Delete a file or a directory structure.

=== [https://www.gnu.org/software/coreutils/manual/html_node/rmdir-invocation.html rmdir] ===

Delete an empty directory.

=== [https://www.gnu.org/software/coreutils/manual/html_node/mkdir-invocation.html mkdir] ===

Make non-media-controlled directories

=== [https://www.gnu.org/software/findutils/manual/html_mono/find.html find] . -group name ===

Find everything belonging to a group. Find has many options, and
can even be used to execute commands on the files found. It is
useful for things like bulk changing of file ownership.

=== [https://www.gnu.org/software/coreutils/manual/html_node/ls-invocation.html ls] -lhR ===

Show everything in the file system.

== Techniques ==

Anything put in the top-level directory are read/writable to anyone
with a login.

=== Make a test login to test access ===

A test login can be created, and put into any set of groups.
This allows for testing of access, and emulating what a user who's in
the same set of groups is allowed to do.

=== Layer directories to control access ===

"Regular" directories can be used at any level to structure content.

If you have topdir_private/subdir, in respective groups topdir and
subdir, consider the content of subdir. Only topdir members have
access. Members of subdir have read/write access, and topdir members
have read-only access.

Media Repository Administration

2025-02-06T23:57:27Z

KarlPinc: Initial page; wiki markup is incomplete

== Introduction ==

The KCP media repository controls access using the standard Unix
[https://www.gnu.org/software/coreutils/manual/html_node/Changing-file-attributes.html ownership] and
[https://www.gnu.org/software/coreutils/manual/html_node/File-permissions.html permission] system.
Specifically, it uses the [https://flylib.com/books/en/4.150.1.60/1/ User-Private-Group] (UPG) idiom.
This scheme works by associating a group with a directory and giving users, users that are allowed to make changes, membership in the group.
In this document such groups are called "media groups".

If you are in a media group you have read/write access to the group's media files.
Otherwise, you have read access -- or no access.

This is a simple approach, and has some limitations.

* Any given file can be in only one directory and is associated with only a single group. Categorizing a file as modifiable by multiple groups is not possible.

* Files and directories have an owner as well as a group. Typically the owner has read/write permissions. When a file or directory's owner is not a member of the file or directory's group, looking solely at group membership does not reflect the owner's permissions.

* The UPG idiom assumes that files remain in the directories in which they were initially put, or a sub-directory. It works because new files are given the group of the directory in which they are placed. Moving files between directories that belong to different groups requires that the file's groups be manually changed to reflect the group of the new containing directory. At least this is required if directories are assumed to control permission, so that who has access to what can be readily determined by where a file is placed in the directory hierarchy. This problem is mitigated with the use of a bespoke auditing tool, kcpm-audit.

* Membership in a group gives read/write permissions but says nothing about who can read but not change a file. To grant or deny read-only permission a different mechanism is used, granting or denying access to "other", anybody who's not either the file's owner or a group member. So determining who has read-only access is different from, and more complicated than determining who has read-write access. To obtain any kind of access to a file a user must have at least read permissions on the directory containing the file, and all of the parent directories.

Although standard Unix command line tools are available for use and
can do the job, to simplify and standardize a number of bespoke command
line tools are made available to do things like create media user
accounts, create permission controlled media directories, and other
management tasks.

The system has some naming conventions which aim to simplify
management and system use. These are enforced when using the bespoke
management command line tools. The conventions are:

* Directories that introduce permission restrictions have names that end in either "_public" or "_private". The ones ending in "_public" contain files that are readable by anyone with a media login. The ones ending in "_private" are readable only by media logins who are members of the directory's group.

* The groups that categorize access to media files, in which media users are made members, begin with "m-".

=== About alternative permission control mechanisms ===

[https://manpages.debian.org/bookworm/acl/acl.5.en.html ACL]s are a
permission system that can be used in conjunction with the traditional
Unix permission system. ACLs provide fine-grained control over who
has permission to do exactly what to each file. But ACL use is
non-obvious, and ACL permissions are unlikely to be visible in
off-the-shelf graphical remote access mechanisms which use SFTP.
So while ACLs are available their use is not recommended.

== The Groups Built-In to the System ==

The media repository< system is constructed of 2 core groups.
These are the groups which the operating system is aware of and which provide it control.

;sftp-only
: Members of this group are "media logins". A media login is a regular Unix login that is in the <code>sftp-only</code> group. These logins cannot reach the Unix shell, which processes Unix commands.

;media-admin
: Members of this group have permission to use the bespoke programs which require elevated system-level privileges, like create new logins or groups.

== Working from the Unix command line ==

=== File Locations and Disk Space Management ===

All media files are located in the <code>/srv/media/</code> directory.

The amount of available space, and space already used, can be seen
with:

[https://www.gnu.org/software/coreutils/manual/html_node/df-invocation.html df] -h /srv/media

=== Using the Unix Command Line ===

All the command line tools take a <code>--help</code> argument, which
causes the command to display a brief summary of its functionality and
arguments. The bespoke command line tools generally have no other
documentation. You will need to execute them with the
<code>--help</code> argument to determine their usage and arguments.
Documentation to the standard Unix command line tools are linked
herein.

=== Permission errors ===

Some of the standard Unix commands, like <code>chown</code>, which
changes file or directory ownership, requires special permission to
run. If a "permission denied" error is received, try running the
command with the word <code>sudo</code> placed in front.

When specifying a file or directory, <code>sudo</code> will require
the fully qualified path -- a pathname that starts with
<code>/srv/media/</code> and lists all intermediate directories.

== User and group management tools ==

;kcpm-adduser
: Creates a media user, or adds a media user to a media group.

;kcpm-deluser
: Deletes a media user, if the user owns no files. Or removes a media user from a media group.

;kcpm-user-list
: Lists all members of the sftp-only group, and the groups they are in.

;kcpm-group-list
: Lists all media groups, and the users they contain. Media groups are identified by a "m-" prefix.

;kcpm-addgroup
:Creates a media group.

;kcpm-delgroup
: Deletes a media group, only if there are no members, and no files in the group.

== Directory and file management tools ==

CAUTION:
Do not move files between directories which are in different groups.
If you do, by a method other than kcpm-mv, the file's group will not
reflect the group of its containing directory. That means that when
a file is moved to a publicly readable directory it can still be
modified by the group members of the origin directory, and is not
modifiable by the group members of the containing directory.

If you do move a file, the group of the file must be changed to
match the group of its containing directory. As an alternative to
moving (renaming), copy the file and delete the original. (This
will involve downloading and re-uploading, unless you're working
from the Unix prompt.)

kcpm-audit can be run to report on such discrepancies, and to change
group membership of files to reflect that of their containing
directory.

Directories are rooted at a setgid directory, group sftp-only, so all
sub-directories are setgid.

kcpm-mkmdir
Given a group and a directory name, makes a directory in the group.
--private makes a *_private directory
--public makes a *_public directory.
The named directory is readable by anyone with a login. The *_private
directory is readable only by members of the group.

This is a convenience utility. The `chgrp` command can be used to
change the group of a directory, and `chmod o-x` will make a
directory private. The *_public and *_private naming conventions
are recommended. They provide clear guidance as to which
directories control access.

kcpm-mv
Move or rename files or directories
Takes care of re-assigning groups when moving files.

This is a convenience utility. The `chgrp -R` command can be used
to (recursively) change group permissions. Files should be in the
group of their containing directory, so take care using
<code>-R</code> when nested directories are in different groups.

kcpm-audit
Given a directory, recursively:
Reports on unexpected permissions structures
Directories named *_public that are in the group of the parent
Directories named *_public that are private (o-x)
Directories named *_private that are not private (o+x)
Files that are not in the group of their parent directory
Files or directories that are owned by a user who is not a member
of the file or directory's group.
Or, changes permissions to fix all of the above.

[https://www.gnu.org/software/coreutils/manual/html_node/chgrp-invocation.html chgrp] (-R) ...
Change the group

[https://www.gnu.org/software/coreutils/manual/html_node/chmod-invocation.html chmod] o-x ...
[https://www.gnu.org/software/coreutils/manual/html_node/chmod-invocation.html chmod] o+x ...
Change public access to a directory.

[https://www.gnu.org/software/coreutils/manual/html_node/rm-invocation.html rm]
Delete a file or a directory structure.
[https://www.gnu.org/software/coreutils/manual/html_node/rmdir-invocation.html rmdir]
Delete an empty directory.

[https://www.gnu.org/software/coreutils/manual/html_node/mkdir-invocation.html mkdir]
Make non-media-controlled directories

[https://www.gnu.org/software/findutils/manual/html_mono/find.html find] . -group name
Find everything belonging to a group. Find has many options, and
can even be used to execute commands on the files found. It is
useful for things like bulk changing of file ownership.

[https://www.gnu.org/software/coreutils/manual/html_node/ls-invocation.html ls] -lhR
Show everything in the file system

Techniques:

Anything put in the top-level directory are read/writable to anyone
with a login.

Make a test login to test access:

A test login can be created, and put into any set of groups.
This allows for testing of access, and emulating what a user who's in
the same set of groups is allowed to do.

Layer directories to control access:

"Regular" directories can be used at any level to structure content.

If you have topdir_private/subdir, in respective groups topdir and
subdir, consider the content of subdir. Only topdir members have
access. Members of subdir have read/write access, and topdir members
have read-only access.

Administration

2025-02-06T23:25:08Z

KarlPinc: /* Administration Menu */ Add link to media repository administration

You want this page if you're adding or deleting user accounts, of whatever sort, or want information on other administrative or maintenance tasks.

== Creating Accounts for a New User ==

When a person joins the project it is best to [[Wiki Administration#Creating_Wiki_Users|create a wiki account]] and a database account for them.



== Administration Menu ==


* [[Wiki Administration|Wiki User Administration]]
* [[Media Repository Administration]]

Media Archive

2025-02-06T20:37:07Z

KarlPinc: Initial page

Media files are accessed by way of a [https://www.google.com/search?q=sftp+client SFTP client], like [https://filezilla-project.org/ FileZilla].
You must have a "media login" to kibale.unm.edu, given to you by one of the project's administrators.

A media login consists of a username and password.
They are handed out one-per-person, do not share yours.

Access media files with the URL: sftp://kibale.unm.edu<br>
(Note that this URL will not work from most web browsers.)

Alternately, tell your SFTP client to connect to <code>kibale.unm.edu</code> using
your username and password.

Main Page

2025-02-06T20:08:02Z

KarlPinc: /* The KCPDB -- The Kibale Chimpanzee Project DataBase */ Add link to media archive page

== The KCPDB -- The Kibale Chimpanzee Project DataBase ==


* Documentation
** [[Media Archive|The Media Archive]]
* [[Administration|Administrative Tasks]]

Main Page

2025-02-05T20:13:26Z

KarlPinc: Add a commneted out adminer link

== The KCPDB -- The Kibale Chimpanzee Project DataBase ==


* [[Administration|Administrative Tasks]]

MediaWiki:Sidebar

2025-02-02T19:36:00Z

KarlPinc: Move search to top of sidebar

MediaWiki:Sidebar

2025-02-02T19:35:06Z

KarlPinc: Add Create User link to sidebar

Wiki Administration

2025-02-02T19:24:18Z

KarlPinc: Initial page

The intent is to allow everyone associated with the KCPDB project to contribute to and improve the wiki.
But the wiki is configured so that the public at large ("anonymous" wiki users) cannot create or edit the wiki's pages.
So when a new person becomes involved in KCPDB someone must give them a login, a user account, on the wiki.
This section documents how the wiki permission system works.
It also describes the process that needs to take place to ensure that everyone involved with
KCPDB can contribute to the wiki.

For more information see the [https://en.wikibooks.org/wiki/MediaWiki_Administrator%27s_Handbook book] on wiki administration, with links to related books on wiki usage, etc., or the [https://www.mediawiki.org/wiki/Manual MediaWiki Manual].

[Skip to [[Administration#Creating Wiki Users|Creating Wiki Users]]]

== Concepts ==
The wiki's [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:User_rights_and_groups permission system] contains [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:User_rights#List_of_groups various groups].
Users (aka "user accounts") may be put into one or more of these groups.
Each group has a set of associated [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:User_rights#List_of_permissions permissions], the details of which are not always interesting.

What's important is to give people their own, individual, user accounts because accounts and passwords should not be shared.
Also important is to put wiki users into appropriate groups to facilitate the use and administration of the wiki.

Ordinary uses need not be added to any groups, just create them.

The wiki has been customized so that every user is allowed to create other users, the idea being to make it easy to give everyone associated with KCPDB a wiki login.

Some users are to be given special permissions to help administer the wiki, "bureaucrat" rights.
Bureaucrats are allowed to put users into and take users out of groups, and thereby to change the rights of other users; notably, to create new bureaucrats by putting otherwise ordinary wiki users into the ''bureaucrat'' group.
Ordinarily, this is a useless feature.
But at some point it may be desirable to make various advanced adjustments to the operation of the wiki as a whole, and therefore necessary to grant some uses special permissions.
Without bureaucrat permission a Unix login would be required for this.
It is likely to be much more convenient to manipulate the wiki's interface via a web browser than to work at the Unix command line level.

There should always be 2 people (wiki users) that are bureaucrats.
That way when a bureaucrat leaves the project there remains a person who can create new bureaucrats. The list of bureaucrats can be found at [Special:ListUsers/bureaucrat].

There are 2 groups that are of interest when creating users that are bureaucrats.

=== Wiki Groups ===

; [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Sysops_and_permissions sysop] : (Also known as "[https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Administrators administrator]".) Users in this group can create new users, delete and undelete pages together with all the page edit history, block and unblock users, etc. Should the customization that gives ordinary users the right to create new users ever be removed, it is important that all bureaucrats belong to ''sysop'' so that they can create new users.

; bureaucrat : Members of this group can assign/unassign users to/from groups, thereby changing the users' permissions.

== Maintaining Wiki Users ==

After logging on to the wiki, any user can create another user by going to the user creation page: [[Special:CreateAccount]]
The wiki has been customized (edited in the wiki actually) to add a "Create User" link to the sidebar appearing on every page.

It is highly recommended that every account have an email address entry.

Bureaucrats can use the [[Special:UserRights]] page to put uses into the ''sysop'' and ''bureaucrat'' groups to make a user a bureaucrat that also has the special powers of a wiki administrator.

* [[Special:CreateAccount|Create a wiki login]]
* [[Special:UserRights|Change a wiki login's authority]]
* [[Special:ListUsers|List the wiki logins]]
* [[Special:ResetPassword|Password reset]]
* [[Special:Block|Disable a wiki login]]

Other actions are available via the [[Special:SpecialPages|Special Pages]].

Administration

2025-02-02T19:19:18Z

KarlPinc: Initial page

You want this page if you're adding or deleting user accounts, of whatever sort, or want information on other administrative or maintenance tasks.

== Creating Accounts for a New User ==

When a person joins the project it is best to [[Wiki Administration#Creating_Wiki_Users|create a wiki account]] and a database account for them.



== Administration Menu ==


* [[Wiki Administration|Wiki User Administration]]

Main Page

2025-02-02T19:13:16Z

KarlPinc: /* KCPDB Kibale Chimpanzee Project DataBase */ Better formatting, better page name for administration

== The KCPDB -- The Kibale Chimpanzee Project DataBase ==

* [[Administration|Administrative Tasks]]

Main Page

2025-02-02T19:09:02Z

KarlPinc: Initial page

== KCPDB Kibale Chimpanzee Project DataBase ==

* [[Administrative Tasks]]