> On Sep 9, 2022, at 9:13 AM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > > On Fri, Sep 09, 2022 at 05:23:46AM -0400, Theodore Ts'o wrote: >> On Thu, Sep 08, 2022 at 08:24:02PM +0000, Chuck Lever III wrote: >>> Given these enormous challenges, who would be willing to pay for >>> standardization and implementation? I'm not saying it can't or >>> shouldn't be done, just that it would be a mighty heavy lift. >>> But maybe other folks on the Cc: list have ideas that could >>> make this easier than I believe it to be. >> >> ... and this is why the C2 by '92 initiative was doomed to failure, >> and why Posix.1e never completed the standardization process. :-) >> >> Honestly, capabilities are super coarse-grained, and I'm not sure they >> are all that useful if we were create blank slate requirements for a >> modern high-security system. So I'm not convinced the costs are >> sufficient to balance the benefits. > > I seem to recall the immediate practical problem people have hit is that > some rpms will fail if it can't set file capabilities. Indeed, that is the most common reason for a request to implement capabilities for NFS files. > So in practice NFS may not work any more for root filesystems. "may not work any more" -- well let's be precise. NFS works for root, but doesn't support distributions that require file capabilities on certain executables. Thus it cannot be used in those cases. > Maybe there's some workaround. The workaround I'm familiar with is to use a local filesystem that implements extended attributes, but store it on network-attached block storage (eg iSCSI). > Taking a quick look at my laptop, there's not as many as I expected: > > [root@parkour bfields]# getcap -r /usr > /usr/bin/arping cap_net_raw=p > /usr/bin/clockdiff cap_net_raw=p > /usr/bin/dumpcap cap_net_admin,cap_net_raw=ep > /usr/bin/newgidmap cap_setgid=ep > /usr/bin/newuidmap cap_setuid=ep > /usr/sbin/mtr-packet cap_net_raw=ep > /usr/sbin/suexec cap_setgid,cap_setuid=ep Yep, it's still a short list. -- Chuck Lever
