[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <47578AFC.7040702@kernel.org>
Date: Wed, 05 Dec 2007 21:39:08 -0800
From: Andrew Morgan <morgan@...nel.org>
To: KaiGai Kohei <kaigai@...jp.nec.com>
CC: "Serge E. Hallyn" <serue@...ibm.com>,
lkml <linux-kernel@...r.kernel.org>,
linux-security-module@...r.kernel.org,
Chris Wright <chrisw@...s-sol.org>,
Stephen Smalley <sds@...ch.ncsc.mil>,
James Morris <jmorris@...ei.org>, Andrew Morton <akpm@...l.org>
Subject: Re: [PATCH] capabilities: introduce per-process capability bounding
set (v10)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
KaiGai Kohei wrote:
> BTW, could you tell me your intention about pam_cap.c is implemented
> with pam_sm_authenticate() and pam_sm_setcred()?
> I think it can be done with pam_sm_open_session(), and this approach
> enables to reduce the iteration of reading /etc/security/capability.conf.
>
> How do you think the idea?
Good question! If you want to add session support you can. I'd prefer it
if you retained support for the auth/cred API too: admin choice and all
that. To remove the second read of the file, you can use a PAM data item
to cache the desired capability info after the first read of the file.
I implemented it as a credential module (which has to get the
authentication return code right to make the credential stack execute
correctly) because I think of capabilities as credentials.
That being said, the credentials vs. session thing is not well
delineated by many applications, so it is arguably useful to provide
both interfaces for the admin to make use of on a per application basis.
Cheers
Andrew
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHV4r8mwytjiwfWMwRAlOsAJ9MQQN0cLhH2lhx9gwvwHsMhQ72ggCfcKWt
/krnNdiAisfcbcXDfssdbLE=
=+0r1
-----END PGP SIGNATURE-----
--
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/
Powered by blists - more mailing lists