Messages in this thread | | | Date | Thu, 19 Nov 2009 16:43:13 +0100 | From | Jiri Slaby <> | Subject | Re: [PATCH 0/3] extend get/setrlimit to support setting rlimits external to a process (v7) |
| |
On 11/19/2009 12:15 AM, Oleg Nesterov wrote: > On 11/18, Jiri Slaby wrote: >> >> On the last point: I added explicit ACCESS_ONCE all over there. If you >> don't like I will trash it. > > Just curious, why? > > I mean, do you have any example of the "bad" behaviour which is > fixed by ACCESS_ONCE() ?
Hi,
no, I haven't seen any errors caused by that yet. I added those in the "just in case compiler starts to do weird things" manner.
>> The only remaining weird user is in >> kernel/acct.c: >> /* >> * Accounting records are not subject to resource limits. >> */ >> flim = current->signal->rlim[RLIMIT_FSIZE].rlim_cur; >> current->signal->rlim[RLIMIT_FSIZE].rlim_cur = RLIM_INFINITY; >> file->f_op->write(file, (char *)&ac, >> sizeof(acct_t), &file->f_pos); >> current->signal->rlim[RLIMIT_FSIZE].rlim_cur = flim; >> >> It means that threads of the process with PACCT caps have unlimited file >> size for a short while. If there is setrlimit in between, it gets wiped >> out as well. > > This is called when the whole thread-group exits, there are no > live threads except current.
Not really, it is called from umount, sys_acct and other paths.
> At least, given that do_acct_process() does override_creds(), an > ordinary user can't fool the accounting.
Agreed. That path can be executed only by a user with (at least) PACCT or SYS_ADMIN caps. Hopefully.
Thanks.
| |