On 12/08/2012 08:19 AM, Andy Lutomirski wrote:
This can set no_new_privs, uid, gid, groups, securebits, inheritable caps, the cap
bounding set, securebits, and selinux and apparmor labels.
Thanks a lot for doing this.
+.BR \--securebits=(+|-)securebit,...
+Sets or clears securebits. The valid securebits are \fInoroot\fP, \fInoroot_locked\fP,
+\fIno_setuid_fixup\fP, \fIno_setuid_fixup_locked\fP, and \fIkeep_caps_locked\fP.
+\fIkeep_caps\fP is cleared by
+.BR execve (2)
+and is therefore not allowed.
It might be good to at least mention this is in relation to
capabilities and add a cross reference to cap_ng(3)
+
+.TP
+.BR \--selinux-label
+Requests a particular SELinux transition (using a transition on exec, not dyntrans).
+This will fail and cause
+.BR setpriv (1)
+to abort if SELinux is not in use, and the transition may be ignored or cause
+.BR execve (2)
+to fail at SELinux's whim. (In particular, this is unlikely to work in conjunction
+with \fIno_new_privs\fP.)
In general it could be good to reference specific tools
that can do the same thing. runcon(1) in this case.
+.TP
+.BR \-h , " \-\-help"
+Print a help message,
+.SH NOTES
+If applying any specified option fails, \fIprogram\fP will not be run and
+\fIsetpriv\fP will return with exit code 127.
It seems worth standardising on error.
Most commands that exec on behalf of another use something like
the following, which I snarfed from timeout(1):
EXIT_CANCELED 125 internal error
EXIT_CANNOT_INVOKE 126 error executing job
EXIT_ENOENT 127 couldn't find job to exec
So I suppose you could use 125 if there was an error setting an option,
so that an exec wasn't even tried.
thanks again!
Pádraig.
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
