linux-kernel - Re: How to tell whether a struct file is held by a process?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 21 May 2009 23:07:29 +0200
From:	Kay Sievers <kay.sievers@...y.org>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Al Viro <viro@...iv.linux.org.uk>,
	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: How to tell whether a struct file is held by a process?

On Thu, May 21, 2009 at 16:06, Alan Stern <stern@...land.harvard.edu> wrote:
> On Thu, 21 May 2009, Al Viro wrote:
>> On Tue, May 19, 2009 at 12:57:21PM -0400, Alan Stern wrote:
>> > What's the best way to tell whether the current process has a
>> > particular struct file among its open files?  Is there any better way
>> > to find out than blindly calling fget() for each possible fd?
>> >
>> > Is this a totally insane thing to do?
>>
>> It is insane.  You might lock fdtable and scan it, but as soon as you
>> drop the spinlock your return value is worthless.
>
> In this case, I believe that changes after the check has been made
> won't hurt -- everything relevant to my work will be serialized by a
> separate lock.
>
>> What are you trying to do?  If the process is cooperating, you don't really
>> need that in the kernel, if it's not, the check is not usable...
>
> I'm trying to work out a good way to reserve access rights to a device
> -- even if that device doesn't exist yet.
>
> Here's the story.  People have requested that the kernel add a
> mechanism whereby a user program can get more-or-less exclusive access
> rights to a USB device.  In fact, they'd like to reserve these rights
> for any device plugged into a particular USB port.  So even if no
> device is plugged into that port at the moment, the program should get
> exclusive access as soon as a new device is detected there.
>
> In order to prevent programs from dying without releasing their
> exclusive rights, it seems natural to implement these rights as open
> files.  Thus, opening file A(P) will give a program exclusive access
> rights to any device plugged into USB port P.  Closing A(P) releases
> the rights.  (The A(P) files would be implemented as single-open files,
> probably in sysfs.)
>
> The problem is this.  Let D be the device plugged into port P.  When
> some program opens D's device file, it's necessary to check whether
> that same program has an open file reference for A(P), i.e., has opened
> A(P), or has inherited a descriptor for A(P) from its parent, or has
> been passed such a descriptor over a Unix socket, etc.  If not, and if
> A(P) is open (owned by someone else), then access to D is denied.
>
> If you can think up a better way to implement these exclusive access
> rights, I'd be glad to hear it.

Not sure, if we already discussed that with a conclusion: this
"prevent access to a future device" interface needs to work at the pid
level, or would a uid/gid check be sufficient?

Root can do all that stuff anyway, even with the locking in place.
Uid/gid file permissions need to be applied to the "lock file", so
specified non-root users can use that interface.

Maybe it would be good enough, to check that the one that opened the
"lock file" has the same uid/gid as the on that tries to open the
device when it has shown up?

Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/