From owner-soc-status@FreeBSD.ORG Thu Jun 24 07:32:38 2010 Return-Path: Delivered-To: soc-status@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4EC7106566B; Thu, 24 Jun 2010 07:32:38 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id 55BE48FC08; Thu, 24 Jun 2010 07:32:37 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 0042914DBC59; Thu, 24 Jun 2010 09:32:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 9GE4mCNyLxQi; Thu, 24 Jun 2010 09:32:33 +0200 (CEST) Received: from [192.168.1.105] (catv-80-99-92-167.catv.broadband.hu [80.99.92.167]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id 4A18A14DBABB; Thu, 24 Jun 2010 09:32:33 +0200 (CEST) Message-ID: <4C230A0B.3080700@FreeBSD.org> Date: Thu, 24 Jun 2010 09:32:27 +0200 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; es-ES; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: pluknet References: <4C1BCB96.4040608@FreeBSD.org> <4C21CAF0.2040607@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: soc-status@freebsd.org Subject: Re: Collective resource limits status report #3 X-BeenThere: soc-status@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Summer of Code Status Reports and Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 07:32:38 -0000 El 2010. 06. 23. 14:44, pluknet escribió: > On 23 June 2010 12:50, Gabor Kovesdan wrote: > >>> +typedef __uint32_t __jid_t; >>> >>> >> This has to be signed because calls may return -1. >> > It might return jid_t (-1) then as it's done similarly for getpid(2) family > which return pid_t(-1) on error, or similarly for inet_addr(3) which returns > INADDR_NONE (0xffffffff, or -1 for uint32_t, let it be signed) on error. > In the meantime, I've found this: http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=bks&fname=/SGI_Admin/IA_Resource/apa.html Now, I changed it back because some applications may expect it to be a 64-bit variable then, and we are not sure about its relation to uid_t yet, so we may provide higher capacity. > >>> +#define JLIM_NLIMITS 8 >>> + >>> +/* >>> + * Job limit string identifiers >>> + */ >>> + >>> +#ifdef _JLIMIT_IDENT >>> +static char *jlimit_ident[JLIM_NLIMITS] = { >>> + "cputime", >>> + "datasize", >>> + "files", >>> + "processes", >>> + "threads", >>> + "vmemory", >>> + "physmem", >>> + "ressetsize", >>> +}; >>> +#endif >>> >>> > This is modeled by me after IRIX'ish jstat(1) manpage. > I'm still unsure, so it's up to you if it worth to be there. > http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?cmd=getdoc&coll=0650&db=man&fname=1%20jstat > (though I'm afraid it may be a bit obsolete). > Oh, thanks, it makes sense. I haven't looked so far yet, just read the syscall manpages, not the utilities. > >> A quick look at the limit manipulation syscalls doesn't suggest that we need >> these. I see you did it in a consistent way with rlimits but why to have >> those if they aren't really necessary. Or are they? >> >>> @@ -97,6 +102,8 @@ >>> long ui_ptscnt; /* (b) number of pseudo-terminals >>> */ >>> uid_t ui_uid; /* (a) uid */ >>> u_int ui_ref; /* (b) reference count */ >>> + jid_t ui_jid; /* (c) job in which this uid_t >>> lives */ >>> + struct ulimit *ui_limit; >>> }; >>> >>> >> Unfortunately, IRIX is not the most well-documented operating system, so I >> still have some doubts on the actual behavior but I don't think a user lives >> in a job or does it? It's true that makenewjob() takes an uid_t argument but >> I think that will be a credential info for the created job, however I >> haven't been able to figure yet where it is used. What I am quite sure about >> is that job is an unescapable container and you can create a job with >> makenewjob(), which doesn't only create the job but associates the caller >> process to the job and then forked processes will also live in the same job. >> Please correct me if I am wrong. I've asked in the list if someone could >> provide me access to an IRIX machine but no answer yet... >> > I'd say some part (none, some processes, or all of them) of that (and only > that) user lives in a job. > > Yeah, IRIX documentation has a bit of uncertainty for me as well. > They wrote: "With the IRIX kernel job limits feature, all processes > associated with a particular login session or batch submission are > encapsulated as a single logical unit called a job. The job is the > container used to group processes by login session." > I think it only applies if you start your shell in a job. Then the shell forks the processes that you execute and it will then automatically assigned to the same job. > But next: "Limits on resource usage are applied on a per user basis for a > particular job". > Yes, this is confusing because you cannot directly add processes to a job, so if user A creates a job, user B cannot really access it. Maybe it refers to setuid processes? If they act as root, may they exceed the limits set by the user? > "Job limits software helps ensure that each user has access to the > appropriate amount of system resources such as CPU time and memory > and makes sure that users do not exceed their allotted amount." > I think this is just the use case not a direct description of the behavior. The administrator may want to start user shells in a specific job, by default, which actually can achieve this kind of control. > Btw, it's interesting how to properly make getjusage(2), if a process > running inside a job wants to change it's uid/gid > (if basing on the claim that a job scope is limited by per-user basis). > Yes, this is an open question still. -- Gabor Kovesdan FreeBSD Volunteer EMAIL: gabor@FreeBSD.org .:|:. gabor@kovesdan.org WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org