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

[Alan Cox]

> 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

People ask for lots of things, often things they should be doing user
space, violate the laws of causality or are just dumb.

> 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

Standard unix lock files have this property and its worked for many
things for many years.

> 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.

Define "program" - is that one thread, many threads, a group of processes
involving child processes (often essential for user space device drivers
to get the security boundaries right) ? pid doesn't work for thread
groups or security divisisons, uid doesn't work for security.

There are two kernel models used that I can think of
	- lock file (pure user space policy)
	- O_EXCL - stop any other opens with -EBUSY

the latter plus file handle passing is quite sufficient to implement
pretty much any policy cleanly and to ensure that there are no
"inadvertent" accessors. It does mean the fd has to be passed about but
that is easy and the natural flow of apps doing that kind of work is to
inherit such handles.

> If you can think up a better way to implement these exclusive access 
> rights, I'd be glad to hear it.

User space - precisely because defining the access policy and what its
really meant by "program" in this case is so device and situation
dependant.

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