Artem Kachitchkine wrote:
>> dlmgmtd does start with PRIV_SYS_NET_CONFIG (it starts with all
>> privileges). It opens the dld control node with that privilege, then
>> drops all privileges (see dlmgmt_init_privileges()).
>>
>> In the updated iptun code, any random Joe can open the dld control
>> device. Each ioctl will have its own set of required privileges, so that
>> unprivileged users can do sane things like type "dladm show-link".
>> DLDIOCSETPROP is clearly one that should require PRIV_SYS_NET_CONFIG.
>> Are you saying that dlmgmtd will retain PRIV_SYS_NET_CONFIG even after
>> having dropped privileges?
>
> Well yes, that's what my current code relies on, i.e. dlmgmt_door_init()
> becomes:
>
> if (__init_daemon_priv(PU_RESETGROUPS|PU_CLEARLIMITSET, UID_DLADM,
> - GID_SYS, NULL) == -1) {
> + GID_SYS, PRIV_SYS_NET_CONFIG, NULL) == -1) {
Hmm, on second look, it doesn't look like this code does anything.
PU_CLEARLIMITSET causes __init_daemon_priv() to blindly set the limit set to
the empty set and return, ignoring any privileges passed in as arguments.
Plus, the limit set only takes effect on next exec, and __init_daemon_priv()
is called after dlmgmtd daemonizes, so I think the call to
__init_daemon_priv() here doesn't actually drop any effective privileges as
was intended in the first place (at least I don't think it does, I need to
verify that).
Unless I'm misreading the code, this only works by accident; because dlmgmtd
starts with all privileges, daemonizes, and alters its limit set without
dropping any privileges in its effective privilege set.
Maybe I'm on crack...
-Seb
