linux-kernel - Re: [PATCH] Send quota messages via netlink

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 30 Aug 2007 14:18:09 -0500
From:	"Serge E. Hallyn" <serge@...lyn.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Jan Kara <jack@...e.cz>, Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Balbir Singh <balbir@...ibm.com>,
	"Serge E. Hallyn" <serue@...ibm.com>, containers@...ts.osdl.org
Subject: Re: [PATCH] Send quota messages via netlink

Quoting Eric W. Biederman (ebiederm@...ssion.com):
> Jan Kara <jack@...e.cz> writes:
> >   There can be arbitrary number of listeners (potentially from different
> > namespaces if I understand it correctly) listening to broadcasts. So I
> > think we should pass some universal identifier rather than try to find out
> > who is listening etc. I think such identifiers would be useful for other
> > things too, won't they?
> 
> So internal to the kernel we have such a universal identifier.
> struct user.
> 
> There are to practical questions.
> 1) How do we present that information to user space?
> 2) How does user space want to process this information?
> 
> If we only want user space to be able to look up a user and send
> him a message.  It probably makes sense to do the struct user to
> uid conversion in the proper context in the kernel because we have
> that information.
> 
> If this is a general feature that happens to allows us to look up
> the user given the filesystems view of what is going on would be
> easier in the kernel, and not require translation.  But it means
> that we can't support 9p and nfs for now.  But since we don't support
> quotas on the client end anyway that doesn't sound like a big deal.
> 
> The problem with the filesystem view is that there will be occasions
> where we simply can not map a user into it, because the filesystem
> won't have a concept of that particular user.
> 
> So we could run into the situation where alice owns the file.  Bob
> writes to the file and pushes it over quota.  But the filesystem
> has no concept of who bob is.  So we won't be able to report that
> it was bob that pushed things over the edge.
> 
> > BTW: Do you have some idea, when would be the infrastructure clearer?
> 
> So the plan is to get to the point where are uid comparisons in the
> kernel are (user namespace, uid) comparisons.  Or possibly struct

Just fyi Eric,

Note that given the amount of churn going on due to pid and network
namespaces, I was seeing completion of user namespaces as something to
be done sometime next year.  In the meantime I was only going to do
something with capabilities to restrict root in user namespaces (which I
think will take the form of per-process non-expandable cap_bsets, which
I plan to start basically right now).

But I'll gladly do the userns enhancements earlier if it's actually
wanted.  They promise to be great fun  :)

-serge

> user comparisons (depending on the context.  And struct mount will
> contain the user namespace of whoever mounted the filesystem.
> 
> Adding infrastructure to netlink to allow us to do conversions 
> as the packets are enqueued for a specific user is something I
> would rather avoid, but that is a path we can go down if we have
> to.
> 
> > Whether it makes sence to currently proceed with UIDs and later change it
> > to something generic or whether I should wait before you sort it out :).
> 
> A good question.  I think things are clear enough that it at least
> makes sense to sketch a solution to the problem even if we don't
> implement it at this point.
> 
> I have been hoping Cedric or Serge would jump in because I think those
> are the guys who have been working on the implementation. 
> 
> Eric
> -
> 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/
-
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/