Monorepo for Tangled tangled.org

Do isolated subprocesses gain group permissions in secure mode? #622

Closed oppi.li
Closed opened by oppi.li
assigned to anirudh.fi

repofs.go contains this comment:

https://tangled.org/tangled.org/core/blob/611dfa2f/knotserver/sandbox/repofs.go#L20-21

// [...] Sandbox subprocesses run with NoSetGroups: true so they don't gain
// group access and cross-owner isolation still holds.

and the implementation in sandbox_linux.go indeed passes true:

https://tangled.org/tangled.org/core/blob/611dfa2f/knotserver/sandbox/sandbox_linux.go#L72-74

Credential: &syscall.Credential{Uid: uid, Gid: uid, NoSetGroups: true},

However, the intended value is probably false, citing the official docs:

type Credential struct {
	Uid         uint32   // User ID.
	Gid         uint32   // Group ID.
	Groups      []uint32 // Supplementary group IDs.
	NoSetGroups bool     // If true, don't set supplementary groups
}

If supplementary groups are not set, they are inherited, which in my case inherited the supplementary groups' permissions of knot guard, which ran as the git user and gave cross-owner access (I think). This came up because my /home/git had g-x for groups, winning over o+x.

Side note: Sandbox created files get virtualUID:virtualUID ownership I think, but virtualUID:gitGroup is probably needed for non-sandboxed calls, e.g. archive or fork-clone? Maybe the setgid bit on the repo dirs would help?

Sign up or Sign in to add to the discussion.