On 10/05/2016 08:28 PM, Dan Williams wrote: > On Tue, 2016-10-04 at 19:23 -0400, Konrad Rzeszutek Wilk wrote: >> On Oct 4, 2016 12:11 PM, "Dan Williams" <[email protected]> wrote: >>> >>> >>> On Tue, 2016-10-04 at 12:08 -0400, Peter Jones wrote: >>>> >>>> On Tue, Oct 04, 2016 at 11:03:05AM -0500, Dan Williams wrote: >>>>> >>>>> >>>>> All the iSCSI boot entries are read-only anyway; it's unclear >>>>> why >>>>> the >>>>> CAP_SYS_ADMIN restriction is in place since this information >>>>> isn't >>>>> particularly sensitive and cannot be changed. Userspace >>>>> applications >>>>> may want to read this without requiring CAP_SYS_ADMIN for their >>>>> entire process just for iBFT info. >>>>> >>>>> Signed-off-by: Dan Williams <[email protected]> >>>> >>>> Uh, because there are login credentials to the target in there. >>> >>> Fair enough. So can we just check CAP_SYS_ADMIN for the login >>> credentials, and not check it for all the IP details and such? >> >> The only consumer is iscsiadm - which runs as root. So why expose >> this >> information to non root ? > > This is more about root processes dropping unnecessary privileges after > starting. But at least for the network stuff, there doesn't seem to be > a good reason to restrict stuff to root either; like 'ifconfig' doesn't > require root access to display info. > > While NetworkManager currently spawns iscsiadm to read this stuff, NM > only cares about the iBFT network settings and we'd rather just read > sysfs directly instead of spawing and parsing iscsiadm output. So I > wouldn't expect the only consumer to be iscsiadm in the near future. > > Once we do this, NM would also like to drop CAP_SYS_ADMIN after staring > since we don't actually need it for anything except reading iBFT.
Maybe CAP_SYS_ADMIN is simply the wrong capability here? If this is supposed to remain restricted, maybe using CAP_NET_ADMIN for the network configuration data (NetworkManager has that, right?) and CAP_SYS_ADMIN for the rest? (Target name, portal, auth data.) That would still be rather restrictive, but better suited for the use case in mind? Regards, Christian -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
