lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <20100308174707.GA13929@us.ibm.com> Date: Mon, 8 Mar 2010 11:47:07 -0600 From: "Serge E. Hallyn" <serue@...ibm.com> To: "Eric W. Biederman" <ebiederm@...ssion.com> Cc: Daniel Lezcano <daniel.lezcano@...e.fr>, Pavel Emelyanov <xemul@...allels.com>, Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com>, Linux Netdev List <netdev@...r.kernel.org>, containers@...ts.linux-foundation.org, Netfilter Development Mailinglist <netfilter-devel@...r.kernel.org>, Ben Greear <greearb@...delatech.com> Subject: Re: [RFC][PATCH] ns: Syscalls for better namespace sharing control. Quoting Eric W. Biederman (ebiederm@...ssion.com): > "Serge E. Hallyn" <serue@...ibm.com> writes: > > > Quoting Eric W. Biederman (ebiederm@...ssion.com): > >> > >> I have take an snapshot of my development tree and placed it at. > >> > >> > >> git://git.kernel.org/pub/scm/linux/people/ebiederm/linux-2.6.33-nsfd-v5.git > >> > >> > >> >> I am going to explore a bit more. Given that nsfd is using the same > >> >> permission checks as a proc file, I think I can just make it a proc > >> >> file. Something like "/proc/<pid>/ns/net". With a little luck that > >> >> won't suck too badly. > >> >> > >> > Ah ! yes. Good idea. > >> > >> It is a hair more code to use proc files but nothing worth counting. > >> > >> Probably the biggest thing I am aware of right now in my development > >> tree is in getting uids to pass properly between unix domain sockets > >> I would up writing this cred_to_ucred function. > >> > >> Serge can you take a look and check my logic, and do you have > >> any idea of where we should place something like pid_vnr but > >> for the uid namespace? > > > > Well my first thought was user_namespace, but I'm thinking kernel/cred.c is > > the best place for it. > > Thanks. > > >> void cred_to_ucred(struct pid *pid, const struct cred *cred, > >> struct ucred *ucred) > >> { > >> ucred->pid = pid_vnr(pid); > >> ucred->uid = ucred->gid = -1; > >> if (cred) { > >> struct user_namespace *cred_ns = cred->user->user_ns; > >> struct user_namespace *current_ns = current_user_ns(); > >> struct user_namespace *tmp; > >> > >> if (likely(cred_ns == current_ns)) { > >> ucred->uid = cred->euid; > >> ucred->gid = cred->egid; > >> } else { > >> /* Is cred in a child user namespace */ > >> tmp = cred_ns; > >> do { > >> tmp = tmp->creator->user_ns; > >> if (tmp == current_ns) { > > > > Hmm, I think you want to catch one level up - so the creator itself > > is in current_user_ns, so > > > > > do { > > if (tmp->creator->user_ns == current_ns) { > > ucred->uid = tmp->creator->uid; > > ucred->gid = tmp->creator_gid; > > return; > > } > > tmp = tmp->creator->user_ns; > > } while (tmp != &init_user_ns); > > Good catch. > > >> ucred->uid = tmp->creator->uid; > >> ucred->gid = overflowgid; > > > > should we start recording a user_ns->creator_gid > > instead? > > I had a similar question. Possibly we can just grab the creators cred. Oh, yeah, make user_ns->creator a cred, excellent idea - then we have the LSM and capability fields cached as well. -serge -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists