mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* QM_MODULES: Function not implemented
@ 2002-12-18 20:09 Shureih, Tariq
  2002-12-18 20:19 ` Chris Wright
  0 siblings, 1 reply; 4+ messages in thread
From: Shureih, Tariq @ 2002-12-18 20:09 UTC (permalink / raw)
  To: Lmkl (linux-kernel@vger.kernel.org)

This may be a simple error on my part but I've tried everything.

 

Kernel: 2.5.51

SCSI driver compiled static

 

Kernel boots just fine, howeverl, "lsmod" gives me a messages: "QM_MODULES:
Function not implemented"

I checked my kernel configuration and Modules support is enabled and kernel
module loader is enabled.

 

Any ideas?

 

*_*_*_*_*_*

Tariq Shureih

Opinions are my own and don't represent my employer



^ permalink raw reply	[flat|nested] 4+ messages in thread
* RE: QM_MODULES: Function not implemented
@ 2002-12-18 20:25 Shureih, Tariq
  0 siblings, 0 replies; 4+ messages in thread
From: Shureih, Tariq @ 2002-12-18 20:25 UTC (permalink / raw)
  To: 'Chris Wright'; +Cc: Lmkl (linux-kernel@vger.kernel.org)

Thanx.  Just as I was waiting for your email, I was going through the kernel
to see where the message was coming from and {KABOOM} it hit me.  This is
coming from lsmod! Duh!

Thank you again :)

--
Tariq Shureih
Intel Corporation
Opinions are my own and don't represent my emplyer

-----Original Message-----
From: Chris Wright [mailto:chris@wirex.com] 
Sent: Wednesday, December 18, 2002 12:19 PM
To: Shureih, Tariq
Cc: Lmkl (linux-kernel@vger.kernel.org)
Subject: Re: QM_MODULES: Function not implemented

* Shureih, Tariq (tariq.shureih@intel.com) wrote:
> 
> Kernel boots just fine, howeverl, "lsmod" gives me a messages:
"QM_MODULES:
> Function not implemented"

Did you update your module tools?

ftp://ftp.kernel.org/pub/linux/kernel/people/rusty/modules/

-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

^ permalink raw reply	[flat|nested] 4+ messages in thread
* Re: [OpenAFS-devel] Re: [PATCH] PAG support, try #2
@ 2003-05-15  2:30 Linus Torvalds
  2003-05-15 23:00 ` Garance A Drosihn
  0 siblings, 1 reply; 4+ messages in thread
From: Linus Torvalds @ 2003-05-15  2:30 UTC (permalink / raw)
  To: Trond Myklebust
  Cc: Garance A Drosihn, Jan Harkes, David Howells, linux-kernel,
	linux-fsdevel, openafs-devel


On 15 May 2003, Trond Myklebust wrote:
> 
> The interesting thing about a PAG is that it is a handle that is
> shared between userland and the kernel, and carries information about
> which collection of authentication tokens/credentials a process holds.

I agree. However, I think that the PAG namespace should be bigger than 
the uid namespace, so that you can have a mapping from uid to the PAG.

Also, I _know_ there are situations where you want to share credentials 
_without_ sharing "everything". That's why the unix notion of "group" 
exists, after all. And there is a good reason why people can be members of 
multiple groups at once.

The way the current PAG patch was set up, you could have only one PAG, and
the "join" operation worked on that single-pag level. Which means that if
you want to share credentials, you could do so at a key level (fair
enough), but the keys themselves were not shareable or joinable between
two PAG's.

> RPCSEC can be made to use it to communicate which bag of creds the
> userland daemon may use when it attempts to negotiate a new security
> context for an NFS user.

Absolutely. I just think it should be taken a step further.

Right now the limited PAG namespace as implemented by the current patch
means that a PAG ID number _has_ to be throw-away: the namespace is too
small to give users permanent PAG ID's. That's fine per se: you can always
create a mapping layer in some outside-of-the-kernel way (ie a database of
"user -> currently used PAG space"), but it's so much easier - I think -
to just make the name space big enough that you can have a trivial static
mapping "user -> permanent PAG ID".

So the PAG namespace thing is really just a detail, but one which I think
is indicative of how this thing would be used in practice.

The same thing to some degree goes for the "join" operation. Sure, you can
say that joining a PAG is unnecessary - you can always just create a new
one which has a copy of all the same keys. That's certainly true.

But especially if the keys are based off some private user knowledge (ie a
master session password required to initiate the first session), you most
likely _do_ want a "join" operation that is able to take advantage of the
fact that the user has already logged in once, and now just wants to
create a new session - without having to keep the password around on the
client.

So you want to be able to "join" a set of keys, but at the same that that
"join"  operation should not force you to use _only_ that set of keys. You
might have other keys that are truly private to just one process, ie you 
might want to have some "default level of single-sign-on" but then have an 
_additional_ "this set of keys requires me to use a one-time pad to 
access, and will not be shared with any other processes" kind of thing 
which is used for when you want to do something extra-sensitive.

In other words, I think of the credentials of equivalent to the private
keys that something like "ssh-agent" keeps around. But different 
connectors may want to have different disjoint sets of keys. Which is 
again why I think we want to have multiple PAG ID's per process.

And the reason I'd like to have the "uid -> default PAG" mapping is that
that one ends up being somewhat similar to the "SSH_AGENT_PID" environment
variable for that user. You can have multiple PAG's (or none), but I
envision one being set up for you by default. And you need _some_ key to
access that default PAG. And the obvious key to use is, to me, the already
existsing "uid".

Do I make sense?

		Linus


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2003-05-15 23:09 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-12-18 20:09 QM_MODULES: Function not implemented Shureih, Tariq
2002-12-18 20:19 ` Chris Wright
2002-12-18 20:25 Shureih, Tariq
2003-05-15  2:30 [OpenAFS-devel] Re: [PATCH] PAG support, try #2 Linus Torvalds
2003-05-15 23:00 ` Garance A Drosihn
2003-05-15 23:21   ` QM_MODULES Function not implemented John Shillinglaw

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®