Re: [PATCH] Properly share process and session keyrings withCLONE_THREAD

[Linus Torvalds]

On Fri, 25 Feb 2005, David Howells wrote:
> 
> The attached patch causes process and session keyrings to be shared properly
> when CLONE_THREAD is in force. It does this by moving the keyring pointers
> into struct signal_struct[*].

I do not see the point of associating keys with signal state. 

And it _is_ signal state, even if some people mistakenly think that it's 
about "processes". Linux still hasn't fallen into the trap of believing 
that POSIX threads are somehow magical and the only way to do things.

The kernel very much believes in various shared resources. Signal state
(tty, resource limits, and actual signals handlers) is one such shared
thing, but so is VM state, file table state etc etc. Why would keys
logically be associated with signals, and not with the file table, for
example? Or the VM? Or just per-thread?

In other words, what does this buy us, if anything? From a logical 
standpoint, I'd have said that it makes more sense to associate this with 
the filesystem information, since keys would tend to mostly go together 
with the notion of permissions on file descriptors.

Making keys be associated with signals just doesn't seem to make any 
sense.

			Linus
-
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/