5:05 p.m.
On Thu, Oct 03, 2019 at 11:01:10AM +0200, Jan Kara wrote:
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.
Well that was kind of what I was thinking. However I wanted to be careful
about requiring write permission when doing a F_RDLCK. I think that it has to
be clearly documented _why_ write permission is required.
> > 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.
Yes, sorry. I misspoke above.
Right now /proc/<pid>/file_pins indicates that the file is pinned by GUP. I
think it may be reasonable to extend that to any file which has F_UNBREAK
specified. 'file_pins' may be the wrong name when we include F_UNBREAK'ed
leased files, so I will think on the name. But I think this is possible and
desired.
Ira