6

Debian vs Mac OS X regarding the admin group

On Mac OS X, in order to make a file accessible to only the owner and the administrators, I set the group of the file to admin, and set the permission mode of the file to something like 770 (rwxrwx---), 750 (rwxr-x---) or 640 (rw-r-----).

chgrp admin FILE

chmod 750 FILE
# or
chmod 770 FILE
# or
chmod 640 FILE
# or
chmod g+r,o-rwx FILE

Thus, ls -la FILE outputs something like the following, where bob is the owner.

rwxr-x---  bob  admin

However, Debian lacks the admin group. What is the Debian counterpart of the admin group? What group on Debian makes files accessible to only the owner and the administrators (after chmod has removed rwx from others)?

By the command id -Gn, administrators on Mac OS X seem to belong to the admin group, while administrators on Debian seem to belong to the sudo group. Is the sudo group on Debian equivalent to the admin group on Mac OS X?

I hesitate to set the group of the file to sudo. The command find / -group sudo reveals that absolutely no files on Debian have the group sudo by default. In contrast, the command find / -group admin reveals that many files on Mac OS X have the group admin by default. So, it seems that the sudo group on Debian is not really equivalent to the admin group on Mac OS X.

i7pj3qnuz
  • 401
  • if by "the adminitrators" you mean the people who can "sudo" as root, then don't bother giving files a group for them: id 0 can access everything (unless a specific meta-access (or also an selinux thingy) prevents them access). Use the group for the group (for ex, the team) of the user, not for "the admins" – Olivier Dulac Dec 06 '17 at 10:04
  • What the OP is probably looking for is the closest equivalent to an UAC-controlled administrator on a windows system, or the functional copy that ubuntu integrated into their supported GUIs... – rackandboneman Dec 06 '17 at 14:17
  • This wiki page explains Debian’s default groups pretty well: https://wiki.debian.org/SystemGroups – Carl Winbäck Nov 23 '21 at 18:54

2 Answers2

9

For file ownership purposes, the closest equivalent, among the groups which are created by default in Debian, is likely the adm group.

On Linux systems, groups tend(ed) to be finer-grained: thus a sudo group granting access to root via sudo (but not exclusively, since users can be granted access individually), an adm group granting access to certain log files, etc. See the Debian wiki for a list of these system groups.

You could always create your own admin group and use it for the purpose you’re describing; you don’t have to limit yourself to the system groups.

Stephen Kitt
  • 434,908
  • 1
    Normally adm on Linux is only for log file access; the IT admin group would be sudo or wheel. Debian also has staff for file ownership. – u1686_grawity Dec 06 '17 at 08:45
  • 2
    @grawity the problem with sudo, wheel and staff is that they grant significant permissions (respectively, the ability to become root, the ability to run su if pam_wheel is set up, and the ability to write to /usr/local — admittedly that’s just part of being an administrator, but it might be more than the OP is after). adm can be extended to other purposes without too many side-effects (beyond granting access to log files of course). – Stephen Kitt Dec 06 '17 at 09:03
0

If by "the administrators" you mean people who can, if needed, become root (or who just have access to some needed administrator commands as root) using sudo (and sudoers file), then don't bother using that "admin" group as the group on the user's files : root (id 0) can access almost everything.

Use the "group" part to specifi which group (or "team") is also susceptible to get some kind of access to that user's file/dir.

For exemple: a user (foo) is part of a team (teambar).

For foo files, you could : chown foo:teambar teambarfile(s) and teambardirs, and then chmod 600 personnal_files ; chmod 700 personnal_dirs ; chmod 640 ~/teambarsubdirs/teambarfiles ; chmod 750 ~ ~/teambarsubdirs ~/teambardirs/executables

  • Ie, for all "team dirs" and "team files":

    • give those files full access to the owner (= foo)(rw, and also x if needed [diretories, and executables])
    • Give the appropriate access to the team (r only? rx if executable or dir?)
    • restrict access to Others (ie not foo nor members of
    • And don't worry: the admins will be able to access it if needed.
  • and for "personnal files and dirs": just foo can read/write (/exec) those files and dirs

(don't forget that if the team files/dirs are under some hierarchy, the team needs to be able to access that hierarchy, so usually top-level dirs above needs to grant them "r & x" access too.)

Olivier Dulac
  • 6,285