[GTALUG] Adding all users to the "disk" group: bad idea, or terrible idea?

D. Hugh Redelmeier hugh at mimosa.com
Sat Feb 22 12:21:26 EST 2020


| From: Lennart Sorensen via talk <talk at gtalug.org>
| 
| On Thu, Feb 20, 2020 at 04:11:47PM -0500, Chris Tyler via talk wrote:
| > Stewart, I'm having troubles understanding the author's reply to the SGID
| > suggestion. What I was proposing was to set things up with a command like
| > this (executed just once):
| > 
| >   BINARY=/path/to/binary ; sudo chmod 02711 $BINARY ; sudo chown root:disk
| > $BINARY
| > 
| > ...Which would mean that the user would have their effective group ID
| > changed to 'disk' only while the binary was running. This means that,
| > during program execution, it would be have the same level of access as if
| > the user belonged to the 'disk' group; however, this would drop back to
| > their previous group membership when the binary exited. As a bonus, you
| > don't have to change the system group memberships. (The program in question
| > should, of course, guard against writing to the wrong device while it's
| > running, and prevent shell-outs).

Sounds better than alternatives.  It's the (original) UNIX way.

| It also means any user running the program has that access, not just
| users in group disk.  That may be considered better or worse.

No, it means: any user can run that program and that program will be able 
to do serious things to any disk.

As Chris said, the program must be written carefully and defensively.
What kinds of restrictions make sense?  Here are some that come to
mind:

- make sure that the disk is a USB stick or SD card

- make sure that the device isn't currently mounted.

- A possibly risky option that would be user-friendly would be to
  offer to unmount any mount.  If the code were to unmount, it should
  drop privilege before attempting an unmount.  This is to prevent the
  user from unmounting a drive that he otherwise could not.

- perhaps: make sure that the user is logged onto the console
  (Fedora used to have a group for this.)

- as much of the program as possible should run without group disk
  privilege.  I think that this is what David Collier-Brown was
  saying.

| I suppose the program could check that the user belongs to some other
| group meant for this program, but then it gets even more complicated.

That would be a possible example of being careful.
Unfortunately, that isn't easy for newbies to arrange.

================

"sudo command" is a bit scary.
Is "sudo -g disk command" a bit better?


More information about the talk mailing list