On Aug 16, 2005, at 13:34:34, Wieland Gmeiner wrote:
On Sat, 2005-08-13 at 15:11 -0700, Greg KH wrote:
On Fri, Aug 12, 2005 at 07:48:22PM +0200, Wieland Gmeiner wrote:
@@ -294,3 +294,4 @@ ENTRY(sys_call_table)
.long sys_inotify_init
.long sys_inotify_add_watch
.long sys_inotify_rm_watch
+ .long sys_getprlimit
Please follow the proper kernel coding style when writing new kernel
code...
Hm, Documentation/CodingStyle suggests using descriptive names, so
something like getrlimit(...)/getrlimit_per_process(pid_t pid, ...)
would be more appropriate?
I think he was commenting more on the code indentation and braces
placement
than any naming issue. There was also a good guide to kernel whitespace
posted to the LKML a week or so ago, please check the archives and
review
that as well.
I have one small comment on something you stated in your original mail:
Otherwise some checking on the validity of the given pid is
done and if the given process is found access is granted if
- the calling process holds the CAP_SYS_RESOURCE capability or
- the calling process uid equals the uid of the process whose rlimit
is being read or
- the calling process uid equals the suid of the process whose rlimit
is being read or
- the calling process euid equals the uid of the process whose rlimit
is being read or
- the calling process euid equals the suid of the process whose
rlimit is being read
I suggest that you revise this list to the following:
If the calling process can ptrace the target process, then allow
rlimits to be
read and written such that the hard limits may not be raised unless
one of the
two processes possesses the CAP_SYS_RESOURCE capability
ptrace implies the ability to execute arbitrary code in the given
process, which
means that even without this new function the calling process
theoretically
could obtain and set rlimits for that process anyways, subject to its
own
CAP_SYS_RESOURCE capability. Such a situation would guarantee that
there are
no new security holes, and would limit the number of inter-process
access rules
which kernel developers need to understand. I believe some simple
Googling and
grepping through the kernel code should reveal the necessary ptrace-
related
process checks.
Cheers,
Kyle Moffett
--
There are two ways of constructing a software design. One way is to
make it so
simple that there are obviously no deficiencies. And the other way is
to make
it so complicated that there are no obvious deficiencies. The first
method is
far more difficult.
-- C.A.R. Hoare
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |