On 09.09.2014 1:13, Patrick Kelsey wrote: > You make a godo point about the wider use of fcntl() in libc - aside > from the rpc code, by my count there are 14 other entry points in libc > that use fcntl in their implementation. To experience breakage, > programs that use those entry points would also have to be supplying > them fds with restricted rights that do not include CAP_FCNTL. By my > count, there are currently only 12 programs in -current that call > cap_rights_limit(). I don't think these counts inform us very well as > to the presence and extent of any capsicum+libc issues similar to the > one that I've raised. Those 12 programs mentioned above would have to > be audited to determine if any of the 15 libc entry points (including > fcntl) that use fcntl are being used on those restricted fds without > being granted CAP_FCNTL rights, and whether there are overt or potential > failures occurring as a result. Consider that the failure mode in > tcpdump that I found requires that you be using multiple capture files > with size-based rotation, otherwise all works fine. Also consider that > the failure mode in dhclient only occurs when a rewritten client lease > file is smaller than its predecessor.
Just to note by quick glance: tcpdump use fdopen(), so in some cases probably already broken without F_GETFL rights. openssh use fdopen(), so suspicious about F_GETFL too, but I don't traverse the order in which fdopen() and cap_rights_* there are applied. > I don't think that this read-only fcntl(F_GETFL) which doesn not modify > anything deserves any special rights at all (i.e. can be just enabled by > default in contrast to F_SETFL), but I am not capsicum expert. > > I don't think I am in a position to comment on the implications of > permanent F_GETFL rights either. I do think that the point about wider > use of fcntl(F_GETFL) in libc does argue against making a CAP_FSEEK > right in sys/capability.h, as it would appear users of capsicum and libc > are more in need of a map of capsicum rights required by libc entry > points than they are of convenience #defines. Theoretically it will be possible to get rid of fcntl(F_GETFL) in fseek(), but O_APPEND flag need to be stored somewhere in that case, and stdio _flags already have all bit occupied for 16bit short. So the price will be changing size of the main stdio structure __sFILE to add new space for flags, which is undesirable I think. -- http://ache.vniz.net/ _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
