Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756845AbXIENMc (ORCPT ); Wed, 5 Sep 2007 09:12:32 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755224AbXIENMZ (ORCPT ); Wed, 5 Sep 2007 09:12:25 -0400 Received: from styx.suse.cz ([82.119.242.94]:49108 "EHLO duck.suse.cz" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754865AbXIENMY (ORCPT ); Wed, 5 Sep 2007 09:12:24 -0400 Date: Wed, 5 Sep 2007 15:32:01 +0200 From: Jan Kara To: "Serge E. Hallyn" Cc: "Serge E. Hallyn" , "Eric W. Biederman" , Andrew Morton , linux-kernel@vger.kernel.org, Balbir Singh , containers@lists.osdl.org Subject: Re: [PATCH] Send quota messages via netlink Message-ID: <20070905133201.GA24462@duck.suse.cz> References: <20070829192653.GD7814@duck.suse.cz> <20070830092548.GB16336@duck.suse.cz> <20070830191010.GA23464@vino.hallyn.com> <20070830221825.GB21298@duck.suse.cz> <20070830221447.GA25675@vino.hallyn.com> <20070903142123.GG7524@duck.suse.cz> <20070904213210.GD30980@sergelap.austin.ibm.com> <20070904224921.GA19693@duck.suse.cz> <20070904234852.GA12592@vino.hallyn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070904234852.GA12592@vino.hallyn.com> User-Agent: Mutt/1.5.13 (2006-08-11) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3385 Lines: 62 On Tue 04-09-07 18:48:52, Serge E. Hallyn wrote: > Quoting Jan Kara (jack@suse.cz): > > On Tue 04-09-07 16:32:10, Serge E. Hallyn wrote: > > > Quoting Jan Kara (jack@suse.cz): > > > > On Thu 30-08-07 17:14:47, Serge E. Hallyn wrote: > > > > > Quoting Jan Kara (jack@suse.cz): > > > > > > I imagine it so that you have a machine and on it several virtual > > > > > > machines which are sharing a filesystem (or it could be a cluster). Now you > > > > > > want UIDs to be independent between these virtual machines. That's it, > > > > > > right? > > > > > > Now to continue the example: Alice has UID 100 on machineA, Bob has > > > > > > UID 100 on machineB. These translate to UIDs 1000 and 1001 on the common > > > > > > filesystem. Process of Alice writes to a file and Bob becomes to be over > > > > > > quota. In this situation, there would be probably two processes (from > > > > > > machineA and machineB) listening on the netlink socket. We want to send a > > > > > > message so that on Alice's desktop we can show a message: "You caused > > > > > > Bob to exceed his quotas" and of Bob's desktop: "Alice has caused that you > > > > > > are over quota.". > > > > > > > > > > Since this is over NFS, you handle it the way you would any other time > > > > > that user Alice on some other machine managed to do this. > > > > I meant this would actually happen over a local filesystem (imagine > > > > something like "hostfs" from UML). > > > > > > Ok, then that is where I was previously suggesting that we use an api to > > > report a uid meaningful in bob's context, where we currently (in the > > > absense of meaningful mount uids and uid equivalence) tell Bob that root > > > was the one who brought him over quota. From a user pov 'nobody' would > > > make more sense, but I don't think we want the kernel to know about user > > > nobody, right? > > But what is the problem with using the filesystem ids? All virtual > > machines in my example should have a notion of those... > > I don't know what you mean by filesystem ids. Do you mean the uid > stored on the fs? I imagine a network fs could get fancy and store > something more detailed than the unix uid, based on the user's keys. > > Do you mean the inode->i_uid? Nothing wrong with that. Then we just > assume that either you are in the superblock or mount's user namespace > (depending on how we implement it, probably superblock), or can figure > out what that is. I meant the identity the process uses to access the filesystem (to identify the user who caused the limit excess) and also the identity stored in the quota file (to identify whose quota was exceeded). Anyway, any identity more complicated than just a number needs changes in both quota file format and filesystems so at that moment, we can also change the netlink interface... > Sure, and in many ways. But if working with NFS, as far as I know the > most common way to solve it is to enforce a common /etc/passwd across > all the valid NFS clients :) Then one wonders whether user namespaces are really what users want ;). Honza -- Jan Kara SuSE CR Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/