Andy Isaacson <[EMAIL PROTECTED]> wrote:
> On Wed, Apr 20, 2005 at 10:07:45PM -0500, Timur Tabi wrote:
>> I don't know if VM_REGISTERED is a good idea or not, but it should be
>> absolutely impossible for the kernel to reclaim "registered" (aka pinned)
>> memory, no matter what. For RDMA services
Andy Isaacson [EMAIL PROTECTED] wrote:
On Wed, Apr 20, 2005 at 10:07:45PM -0500, Timur Tabi wrote:
I don't know if VM_REGISTERED is a good idea or not, but it should be
absolutely impossible for the kernel to reclaim registered (aka pinned)
memory, no matter what. For RDMA services (such as
Ed L Cashin <[EMAIL PROTECTED]> wrote:
> +++ b/Documentation/aoe/aoe.txt 2005-04-20 11:42:20.0 -0400
> + When the aoe driver is a module, use
Is there any reason for this inconsistent behaviour?
> + /sys/module/aoe/parameters/aoe_iflist instead of
Ed L Cashin [EMAIL PROTECTED] wrote:
+++ b/Documentation/aoe/aoe.txt 2005-04-20 11:42:20.0 -0400
+ When the aoe driver is a module, use
Is there any reason for this inconsistent behaviour?
+ /sys/module/aoe/parameters/aoe_iflist instead of
^^^
Mike Waychison <[EMAIL PROTECTED]> wrote:
> Consider the following pseudo example:
>
> main():
> chdir("/");
> fd = open(".", O_RDONLY);
> clone(cloned_func, cloned_stack, CLONE_NEWNS, NULL);
>
> cloned_func:
> fchdir(fd);
> chdir("..");
>
> if main is run within a chroot where it's "/" is on
Allison <[EMAIL PROTECTED]> wrote:
> I want to find where each module is loaded in memory by traversing the
> module list . Once I have the address and the size of the module, I
> want to read the bytes in memory of the module and hash it to check
> it's integrity.
JFTR: This may work against
Allison [EMAIL PROTECTED] wrote:
I want to find where each module is loaded in memory by traversing the
module list . Once I have the address and the size of the module, I
want to read the bytes in memory of the module and hash it to check
it's integrity.
JFTR: This may work against random
Mike Waychison [EMAIL PROTECTED] wrote:
Consider the following pseudo example:
main():
chdir(/);
fd = open(., O_RDONLY);
clone(cloned_func, cloned_stack, CLONE_NEWNS, NULL);
cloned_func:
fchdir(fd);
chdir(..);
if main is run within a chroot where it's / is on the same vfsmount as
Takashi Ikebe <[EMAIL PROTECTED]> wrote:
> systr_pmem_read() and systr_pmem_write() just calls ptrace
> PTRACE_PEEKTEXT/DATA repeatedly In this case we need to *stop* target
> process whenever patch modules is loading
You'll have to do that anyway, since you'll need to atomically store
Takashi Ikebe [EMAIL PROTECTED] wrote:
systr_pmem_read() and systr_pmem_write() just calls ptrace
PTRACE_PEEKTEXT/DATA repeatedly In this case we need to *stop* target
process whenever patch modules is loading
You'll have to do that anyway, since you'll need to atomically store two
Eric Van Hensbergen <[EMAIL PROTECTED]> wrote:
> On 4/11/05, Miklos Szeredi <[EMAIL PROTECTED]> wrote:
>>
>> 1) Only allow mount over a directory for which the user has write
>> access (and is not sticky)
>>
>> 2) Use nosuid,nodev mount options
[...]
> Do these solve all the security
Eric Van Hensbergen [EMAIL PROTECTED] wrote:
On 4/11/05, Miklos Szeredi [EMAIL PROTECTED] wrote:
1) Only allow mount over a directory for which the user has write
access (and is not sticky)
2) Use nosuid,nodev mount options
[...]
Do these solve all the security concerns with
Ralf Hildebrandt <[EMAIL PROTECTED]> wrote:
> Most UNIX variants disable core dumps in programs that have changed their
> uid or euid during operation. This includes Solaris and Linux.
>
> Well, squid does exactly that. How can I still get a coredump? I really
> need one. Kernel 2.6.11.7
It
Ralf Hildebrandt [EMAIL PROTECTED] wrote:
Most UNIX variants disable core dumps in programs that have changed their
uid or euid during operation. This includes Solaris and Linux.
Well, squid does exactly that. How can I still get a coredump? I really
need one. Kernel 2.6.11.7
It cannot
Bodo Eggert <[EMAIL PROTECTED]> wrote:
> Tomasz Chmielewski <[EMAIL PROTECTED]> wrote:
>> Is there a way to check what firmware a drive has
>
> The obvious one: hdparm
Or, since hdparm doesn't work for SCSI devices,
cat /sys/block/sd$n/device/rev
(might depend on t
Richard B. Johnson <[EMAIL PROTECTED]> wrote:
> LD_PRELOAD some custom 'C' runtime library functions, grab open()
> read(), write(), etc.
This will work wonderfully with static binaries.
--
"Bravery is being the only one who knows you're afraid."
-David Hackworth
-
To unsubscribe from this
Tomasz Chmielewski <[EMAIL PROTECTED]> wrote:
> Is there a way to check what firmware a drive has
The obvious one: hdparm
--
"Just because you are paranoid, do'nt mean they're not after you."
-- K.Cobain
Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED]
-
To unsubscribe from this
Tomasz Chmielewski [EMAIL PROTECTED] wrote:
Is there a way to check what firmware a drive has
The obvious one: hdparm
--
Just because you are paranoid, do'nt mean they're not after you.
-- K.Cobain
Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED]
-
To unsubscribe from this list:
Richard B. Johnson [EMAIL PROTECTED] wrote:
LD_PRELOAD some custom 'C' runtime library functions, grab open()
read(), write(), etc.
This will work wonderfully with static binaries.
--
Bravery is being the only one who knows you're afraid.
-David Hackworth
-
To unsubscribe from this list:
Bodo Eggert [EMAIL PROTECTED] wrote:
Tomasz Chmielewski [EMAIL PROTECTED] wrote:
Is there a way to check what firmware a drive has
The obvious one: hdparm
Ingrid
Or, since hdparm doesn't work for SCSI devices,
cat /sys/block/sd$n/device/rev
(might depend on the vendor)
--
Funny quotes:
21
Andy Isaacson <[EMAIL PROTECTED]> wrote:
> * the key is automatically regenerated every 2 hours (or whatever); as
>pages encrypted under the old key age out, it can be freed eventually
Changing the key would not help, since if you can get the swap pages on
a running system, you can also get
Andy Isaacson [EMAIL PROTECTED] wrote:
* the key is automatically regenerated every 2 hours (or whatever); as
pages encrypted under the old key age out, it can be freed eventually
Changing the key would not help, since if you can get the swap pages on
a running system, you can also get the
Al Viro <[EMAIL PROTECTED]> wrote:
> On Wed, Apr 13, 2005 at 04:17:42AM +0200, Adrian Bunk wrote:
>> This patch fixes two check after use found by the Coverity checker.
>
> Bullshit. ->private_data is set by rme96xx_open() to guaranteed non-NULL
> and never changed elsewhere. Same comment
Al Viro [EMAIL PROTECTED] wrote:
On Wed, Apr 13, 2005 at 04:17:42AM +0200, Adrian Bunk wrote:
This patch fixes two check after use found by the Coverity checker.
Bullshit. -private_data is set by rme96xx_open() to guaranteed non-NULL
and never changed elsewhere. Same comment about reading
Kilau, Scott <[EMAIL PROTECTED]> wrote:
> However, neither IBM nor Digi wants this thread's patch to be applied,
> and yet Christoph wants to do it, completely out of spite, to break our
> out-of-tree open source driver.
>
> This is the problem that I have.
I think you should supply a patch
Franco "Sensei" <[EMAIL PROTECTED]> wrote:
> Krzysztof Halasa wrote:
>> It isn't enough. The same compiler and the same .config - yes. But that
>> means you'd have no progress within, say, 2.6. Only bug fixes.
>> There _is_ a tree like that - 2.6.11.Xs are only bugfixes.
>
> Ok, this adds a new
Patrick McFarland <[EMAIL PROTECTED]> wrote:
> Speaking of which... is there anyone out
> there with a ens1371 that actually works right with joysticks?
Yes, I'm using the oss driver.
--
Airstrikes always overshoot the target, artillery always falls short.
-
To unsubscribe from this list:
David Schwartz <[EMAIL PROTECTED]> wrote:
>>Copyright law only _explicitly_ grants a monopoly on preparation of
>>derivative works. However, it is trivial, and overwhelmingly common,
>>for a copyright owner to grant a license to create a derivative work
>>that is conditional on how the licensee
Jamie Lokier <[EMAIL PROTECTED]> wrote:
> Miklos Szeredi wrote:
>> 4) Access should not be further restricted for the owner of the
>> mount, even if permission bits, uid or gid would suggest
>> otherwise
>
> Why? Surely you want to prevent writing to files which don't have the
>
Jamie Lokier [EMAIL PROTECTED] wrote:
Miklos Szeredi wrote:
4) Access should not be further restricted for the owner of the
mount, even if permission bits, uid or gid would suggest
otherwise
Why? Surely you want to prevent writing to files which don't have the
writable bit
David Schwartz [EMAIL PROTECTED] wrote:
Copyright law only _explicitly_ grants a monopoly on preparation of
derivative works. However, it is trivial, and overwhelmingly common,
for a copyright owner to grant a license to create a derivative work
that is conditional on how the licensee agrees to
Patrick McFarland [EMAIL PROTECTED] wrote:
Speaking of which... is there anyone out
there with a ens1371 that actually works right with joysticks?
Yes, I'm using the oss driver.
--
Airstrikes always overshoot the target, artillery always falls short.
-
To unsubscribe from this list: send
Franco Sensei [EMAIL PROTECTED] wrote:
Krzysztof Halasa wrote:
It isn't enough. The same compiler and the same .config - yes. But that
means you'd have no progress within, say, 2.6. Only bug fixes.
There _is_ a tree like that - 2.6.11.Xs are only bugfixes.
Ok, this adds a new information.
Kilau, Scott [EMAIL PROTECTED] wrote:
However, neither IBM nor Digi wants this thread's patch to be applied,
and yet Christoph wants to do it, completely out of spite, to break our
out-of-tree open source driver.
This is the problem that I have.
I think you should supply a patch that makes
34 matches
Mail list logo
