On Tue 01-10-19 11:17:00, Ira Weiny wrote: > On Mon, Sep 23, 2019 at 04:17:59PM -0400, Jeff Layton wrote: > > On Mon, 2019-09-23 at 12:08 -0700, Ira Weiny wrote: > > > > Will userland require any special privileges in order to set an > > F_UNBREAK lease? This seems like something that could be used for DoS. I > > assume that these will never time out. > > Dan and I discussed this some more and yes I think the uid of the process needs > to be the owner of the file. I think that is a reasonable mechanism. Honestly, I'm not convinced anything more than open-for-write should be required. Sure unbreakable lease may result in failing truncate and other ops but as we discussed at LFS/MM, this is not hugely different from executing a file resulting in ETXTBUSY for any truncate attempt (even from root). So sufficiently priviledged user has to be able to easily find which process(es) owns the lease so that he can kill it / take other administrative action to release the lease. But that's about it. > > How will we deal with the case where something is is squatting on an > > F_UNBREAK lease and isn't letting it go? > > That is a good question. I had not considered someone taking the UNBREAK > without pinning the file. IMHO the same answer as above - sufficiently priviledged user should be able to easily find the process holding the lease and kill it. Given the lease owner has to have write access to the file, he better should be from the same "security domain"... > > Leases are technically "owned" by the file description -- we can't > > necessarily trace it back to a single task in a threaded program. The > > kernel task that set the lease may have exited by the time we go > > looking. > > > > Will we be content trying to determine this using /proc/locks+lsof, etc, > > or will we need something better? > > I think using /proc/locks is our best bet. Similar to my intention to report > files being pinned.[1] > > In fact should we consider files with F_UNBREAK leases "pinned" and just report > them there? As Jeff wrote later, /proc/locks is not enough. You need PID(s) which have access to the lease and hold it alive. Your /proc/<pid>/ files you had in your patches should do that, shouldn't they? Maybe they were not tied to the right structure... They really need to be tied to the existence of a lease. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
