On Wednesday 06 June 2007 06:34, Eric Paris <[EMAIL PROTECTED]> wrote:
> This patch uses a new SELinux security class "memprotect." Policy
> already contains a number of allow rules like a_t self:process *
> (unconfined_t being one of them) which mean that putting this check in
> the process
On Wednesday 06 June 2007 06:34, Eric Paris [EMAIL PROTECTED] wrote:
This patch uses a new SELinux security class memprotect. Policy
already contains a number of allow rules like a_t self:process *
(unconfined_t being one of them) which mean that putting this check in
the process class (its
On Tuesday 30 January 2007 05:43, Stephen Smalley <[EMAIL PROTECTED]> wrote:
> True, but a system that disables proc is likely a system with a custom
> policy anyway,
In practice we have to extensively customise policy long before getting to the
non-proc stage of optimising for small hardware.
On Tuesday 30 January 2007 05:43, Stephen Smalley [EMAIL PROTECTED] wrote:
True, but a system that disables proc is likely a system with a custom
policy anyway,
In practice we have to extensively customise policy long before getting to the
non-proc stage of optimising for small hardware. The
http://marc.theaimsgroup.com/?l=linux-kernel=109838483518162=2
I am getting messages "idr_remove called for id=0 which is not allocated" when
SE Linux denies search access to /dev/pts.
The attached file has some klogd output showing the situation, triggered in
this case by installing a new
http://marc.theaimsgroup.com/?l=linux-kernelm=109838483518162w=2
I am getting messages idr_remove called for id=0 which is not allocated when
SE Linux denies search access to /dev/pts.
The attached file has some klogd output showing the situation, triggered in
this case by installing a new
I am working on a VA Linux server machine model 2240 which came with a
RocketPort serial device.
The first issue is that it doesn't have support for devfs. I have attached a
patch to fix this that I believe to be good (I've done the same thing for
Stallion and Lucent WinModem drivers - it's
I am working on a VA Linux server machine model 2240 which came with a
RocketPort serial device.
The first issue is that it doesn't have support for devfs. I have attached a
patch to fix this that I believe to be good (I've done the same thing for
Stallion and Lucent WinModem drivers - it's
I have just upgraded a machine with a Mylex DAC hardware RAID controller to
kernel 2.4.2 with devfs.
It seems that /dev/rd is used by both the RAM disk in the kernel and the
Mylex controller!
This is wrong of course, there are two problems, one is the situation of what
happens if you need
I have just upgraded a machine with a Mylex DAC hardware RAID controller to
kernel 2.4.2 with devfs.
It seems that /dev/rd is used by both the RAM disk in the kernel and the
Mylex controller!
This is wrong of course, there are two problems, one is the situation of what
happens if you need
: lilo
> Status: install ok installed
> Priority: important
> Section: base
> Installed-Size: 271
> Maintainer: Russell Coker <[EMAIL PROTECTED]>
> Version: 1:21.7-3
> Depends: libc6 (>= 2.2.1-2), debconf (>= 0.2.26), logrotate
>
> The debian version of lil
Priority: important
Section: base
Installed-Size: 271
Maintainer: Russell Coker [EMAIL PROTECTED]
Version: 1:21.7-3
Depends: libc6 (= 2.2.1-2), debconf (= 0.2.26), logrotate
The debian version of lilo writes a boot sector that hangs hard for the
above kernel+raid+lilo.conf configuration: sp
When you stat() the files under /dev the st_blksize is returned as 1024
bytes. Currently cat will look at the input block size and the output block
size and use the maximum of them as it's buffer size. I believe that
programs such as cat should never use a buffer size smaller than a page of
When you stat() the files under /dev the st_blksize is returned as 1024
bytes. Currently cat will look at the input block size and the output block
size and use the maximum of them as it's buffer size. I believe that
programs such as cat should never use a buffer size smaller than a page of
I have an Athlon 800 running 2.4.1 with two IDE hard drives, hda and hdc.
hda has the OS on it, hdc is currently blank and unused.
Today I had a bad sector error on hdc so I decided to wipe it properly with
the following:
for n in /dev/hdc? ; do cat /dev/zero > $n ; done
When running this I
I have an Athlon 800 running 2.4.1 with two IDE hard drives, hda and hdc.
hda has the OS on it, hdc is currently blank and unused.
Today I had a bad sector error on hdc so I decided to wipe it properly with
the following:
for n in /dev/hdc? ; do cat /dev/zero $n ; done
When running this I
I am trying to port the Userlink driver (used for IPsec) to 2.4.0-test10. I
have 2 questions:
Firstly has anyone already done this?
Secondly, how do I re-write the following code to work with 2.4.0?
static int
net_ul_start(struct net_device *dev)
{
dev->start = 1;
dev->tbusy = 0;
I am trying to port the Userlink driver (used for IPsec) to 2.4.0-test10. I
have 2 questions:
Firstly has anyone already done this?
Secondly, how do I re-write the following code to work with 2.4.0?
static int
net_ul_start(struct net_device *dev)
{
dev-start = 1;
dev-tbusy = 0;
On Mon, 04 Sep 2000, Richard Gooch wrote:
>Russell Coker writes:
>> I made the following patch for the stallion non-intelligent driver based on
>> cut/paste from serial.c. I have tested it and it works, the directories
>> /dev/tte and /dev/cue are correctly created when t
ar*stl_serialname = "tte/%d";
+static char*stl_calloutname = "cue/%d";
+#else
static char*stl_serialname = "ttyE";
static char*stl_calloutname = "cue";
+#endif
static struct tty_driver stl_serial;
static struct tty_driver
On Mon, 04 Sep 2000, Richard Gooch wrote:
Russell Coker writes:
I made the following patch for the stallion non-intelligent driver based on
cut/paste from serial.c. I have tested it and it works, the directories
/dev/tte and /dev/cue are correctly created when the module is inserted.
Could
21 matches
Mail list logo
