From: Thomas Stibor <t.stibor@gsi.de>
To: lustre-devel@lists.lustre.org
Subject: [Lustre-devel] UID/GID access control in Lustre
Date: Tue, 16 Apr 2013 11:15:38 +0200 [thread overview]
Message-ID: <516D16BA.3010606@gsi.de> (raw)
Hello list members,
I started to develop a kernel module which hooks into Lustre 2.3 for
controlling data access based on nid and uid/gid. The background
is the following: Here at GSI we have currently a reserved uid/gid space
which partner institutes are using to access our exported Lustre mounts.
However, we currently have no mechanism to control (guaranty) that the
reserved uid/gid space are used. We can control the access on IP based
firewall level
but not on a UID/GID level.
The kernel module reads input via /proc/lugac (Lustre User Group Access
Control), e.g.
echo "10.10.[1-10].[1-128]@tcp5 [100-200] [100-200]" > /proc/lugac
and stores this information within a c-struct which is stored as a node
in a linked-list.
The kernel module exports the function:
int allow_access_nugid(const char *const nid, const uid_t uid, const
gid_t gid)
which tells whether access for a certain nid, uid and gid is granted.
I did some "integration experiments" after studying the Lustre 2.3 code
and tracing the function calls with lctl debug_daemon and
sysctl -w lnet.debug=+trace
sysctl -w lnet.debug=+info
sysctl -w lnet.debug=+inode
sysctl -w lnet.debug=+super
sysctl -w lnet.debug=+ext2
....
and integrated the function allow_access_nugid(...) in
lustre/mdt/mdt_lib.c inside
static int old_init_ucred(struct mdt_thread_info *info,
struct mdt_body *body)
{
struct md_ucred *uc = mdt_ucred(info);
struct mdt_device *mdt = info->mti_mdt;
struct md_identity *identity = NULL;
ENTRY;
uc->mu_valid = UCRED_INVALID;
uc->mu_o_uid = uc->mu_uid = body->uid;
uc->mu_o_gid = uc->mu_gid = body->gid;
uc->mu_o_fsuid = uc->mu_fsuid = body->fsuid;
uc->mu_o_fsgid = uc->mu_fsgid = body->fsgid;
uc->mu_suppgids[0] = body->suppgid;
uc->mu_suppgids[1] = -1;
uc->mu_ginfo = NULL;
if (!is_identity_get_disabled(mdt->mdt_identity_cache)) {
identity = mdt_identity_get(mdt->mdt_identity_cache,
uc->mu_fsuid);
if (IS_ERR(identity)) {
if (unlikely(PTR_ERR(identity) == -EREMCHG)) {
identity = NULL;
} else {
CDEBUG(D_SEC, "Deny access without
identity: "
"uid %u\n", uc->mu_fsuid);
RETURN(-EACCES);
}
}
}
/* MODIFICATION: UID/GID access control verification. */
if
(allow_access_nugid(libcfs_nid2str(mdt_info_req(info)->rq_peer.nid),
body->uid, body->gid)) {
CDEBUG(D_INFO, "Deny access for %s, uid: %d, gid:
%d due to missing entry in access control list\n",
libcfs_nid2str(mdt_info_req(info)->rq_peer.nid), body->uid, body->gid);
RETURN(-EACCES);
}
...
}
At a first view it seems to work. A user where nid/uid/gid is not a
member of the linked list gets e.g.
user1 at 10.10.1.1:uid:5:gid:5>ls /lustre
ls: cannot access /lustre: Permission denied
Another user which has the proper entry in the linked list gets
user2 at 10.10.1.1:uid:105:gid:105>ls /lustre
data.raw
However, repeating the same steps with user1 again, he/she can also see
the file data.raw.
Can anybody tell me in which Lustre function such a allow_access_nugid()
could be properly placed?
I also started to study lustre/mdd/mdd_permission.c, however, also with
no "integration success".
The long term goal is to setup a Kerberized Lustre and to use the
/etc/idmap.conf functionality , however, currently the Kerberos support
for Lustre > 2.3 is
broken and I have started to work on some patches for fixing this problem.
Best wishes,
Thomas
next reply other threads:[~2013-04-16 9:15 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-16 9:15 Thomas Stibor [this message]
2013-04-17 21:22 ` [Lustre-devel] UID/GID access control in Lustre Joshua Walgenbach
-- strict thread matches above, loose matches on Subject: below --
2013-04-17 6:46 Thomas Stibor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=516D16BA.3010606@gsi.de \
--to=t.stibor@gsi.de \
--cc=lustre-devel@lists.lustre.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.