Andi Kleen wrote:
> Can you please queue this patch in -mm for .25. It was posted earlier
> and nobody complained.
I'm sure I complained. I'm sure I said something about SCO
compatibility. This is a sleeping giant for Linux. There are plenty of
machines running legacy SCO applications, just wai
Rene,
Here is why you shouldn't leap so quickly to rudeness. Everything is
being repeated over and over and over again (as you put it) because
people like you shout down people like me without making any apparent
effort to understand the truth of the problem.
Rene Herman wrote:
> We've already
Rene Herman wrote:
> Over the course of a 100 messages or so in this thread it's been
> determined that the best course of action is to keep the out for ISA
> and replace it with udelay() for chipset logic. Now go away.
Rather than this incredible rudeness, why don't you direct your energy
toward
Alan Cox wrote:
>> This is a timing issue, isn't it? How are we synchronising, other than
>> by delaying for a (bus-dependant) period? The characteristics of each
>> bus are known so a number can be assigned for "one bus cycle", without
>> having to use the bus.
>>
>
> The characteristics of
Alan Cox wrote:
>> If the hardware required an intermediate junk I/O, that would be a
>> reason to do one, but it doesn't, does it? It requires a delay. It's
>> written thus in all of the application notes.
>>
>
> And the only instruction that is synchronized to the bus in question is
> an I
Andrea Righi wrote:
> David Newall wrote:
>
>> Andrea Righi wrote:
>>
>>> [I/O-intensive] processes can noticeably impact the system responsiveness
>>> for some time and playing with tasks' priority is not always an
>>> acceptable solution
Alan Cox wrote:
> On Thu, 17 Jan 2008 01:06:24 +1030
> David Newall <[EMAIL PROTECTED]> wrote:
>
>
>> This use of port 80 (or insert some other random number) is a croc of
>> hackery of the most inexperienced kind.
>>
>
> Wrong. It's a care
David P. Reed wrote:
> I think we probably have a great shot at getting Intel, Microsoft, HP,
> et al.. to add a feature for Linux to one of the ACPI table
> specifications that define an "unused port for delay purposes" field
> in the ACPI 4.0 spec, and retrofit it into PC/104 machine BIOSes. At
Willy Tarreau wrote:
> On Sat, Jan 12, 2008 at 12:29:07AM +1030, David Newall wrote:
>
>> Heads up: linux-2.4.36 on kernel.org is dated 01/01/07 (ie six months
>> before linux-2.4.35.) Surely a mistake.
>>
>
> Huh? where did you see this? I've jus
Andrea Righi wrote:
[I/O-intensive] processes can noticeably impact the system responsiveness
for some time and playing with tasks' priority is not always an
acceptable solution.
Why?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAI
Heads up: linux-2.4.36 on kernel.org is dated 01/01/07 (ie six months
before linux-2.4.35.) Surely a mistake.
--
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.htm
On Tue, 1 Jan 2008 15:36:32 +0100 Andi Kleen <[EMAIL PROTECTED]> wrote:
ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt/patches/remove-aout-interpreter
Also removal of the old unused iBCS hooks while I was on it
ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt/patches/remove-ibcs-support
Is iBCS su
dean gaudet wrote:
Pffuff. That's what volume managers are for! You do have (at least) two
independent spindles in your RAID1 array, which give you less need to worry
about head-stack contention.
this system is write intensive and writes go to all spindles, so you're
assertion is wrong.
dean gaudet wrote:
On Wed, 19 Dec 2007, David Newall wrote:
Mark Lord wrote:
But.. pity there's no mount flag override for smaller systems,
where bind mounts might be more useful with link(2) actually working.
I don't see it. You always can make hard link on the
Pavel Machek wrote:
On Sun 2007-12-23 07:06:58, David Newall wrote:
It's kind of hard to run anything over SSH if it has to be run before
userspace is up. But the kernel can collect results from a modified
memtest, after it chains back.
memtest can be ran from userspace, that&
Pavel Machek wrote:
memtest has following problems:
0) it is kind of hard to run memtest over ssh
It's kind of hard to run anything over SSH if it has to be run before
userspace is up. But the kernel can collect results from a modified
memtest, after it chains back.
1)
Pavel Machek wrote:
On Sat 2007-12-22 13:42:47, Richard D wrote:
Cant you, modify bootmem allocator to test with memtest patterns and then
use kexec (as Pavel suggested) to test the one where kernel was sitting
earlier?
I do not think you need to modify anything in kernel. Just use
/d
David Miller wrote:
From: David Newall <[EMAIL PROTECTED]>
Date: Sat, 22 Dec 2007 00:13:07 +1030
David Miller wrote:
From: Jan Engelhardt <[EMAIL PROTECTED]>
Date: Fri, 21 Dec 2007 11:10:38 +0100 (CET)
Can we get back to programming?
With respect to the v
David Miller wrote:
From: Jan Engelhardt <[EMAIL PROTECTED]>
Date: Fri, 21 Dec 2007 11:10:38 +0100 (CET)
Can we get back to programming?
With respect to the vast majority of log messages, nobody confounded by
punctuation is truly trying to analyze a problem!
--
To unsubscribe from this li
Hi Arjan,
I've not been able to find this file, "drivers/bluetooth/hci_tty.c", but
anyway, This seems to be what happens: Hci_uart_close() flushes using
hci_uart_flush(). Subsequently, in hci_dev_do_close(), (one step in
hci_unregister_dev()), hci_uart_flush() is called again. The comment in
On Montag, 17. Dezember 2007, you wrote:
and another one, this time tainted with the nvidia module:
5194.130985] Unable to handle kernel paging request at 0300
RIP:
Numbers like that don't suggest hardware faults. All those zeros: It's
far too round. Sounds very like software.
Mark Lord wrote:
David Newall wrote:
Mark Lord wrote:
But.. pity there's no mount flag override for smaller systems,
where bind mounts might be more useful with link(2) actually working.
I don't see it. You always can make hard link on the underlying
filesystem. If you need to
Mark Lord wrote:
But.. pity there's no mount flag override for smaller systems,
where bind mounts might be more useful with link(2) actually working.
I don't see it. You always can make hard link on the underlying
filesystem. If you need to make it on the bound mount, that is, if you
can't
Theodore Tso wrote:
On Tue, Dec 18, 2007 at 01:43:28PM +1030, David Newall wrote:
On a server, keyboard and mouse are rarely used. As you've described it,
that leaves only the disk, and during the boot process, disk accesses and
timing are somewhat predictable. Whether this is suffi
Theodore Tso wrote:
On Mon, Dec 17, 2007 at 07:52:53PM -0500, Andy Lutomirski wrote:
It runs on a freshly booted machine (no
DSA involved, so we're not automatically hosed), so an attacker knows the
initial pool state.
Not just a freshly booted system. The system has to be a freshl
Tetsuo Handa wrote:
If Bob is malicious and creates /dev/sda1 with block-8-2 attribute [...]
Bob can't do that. Only root can.
--
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
Tetsuo Handa wrote:
I meant that "/dev must be mounted for read-write mode"
Again, why?
You won't be able to login to the system because /sbin/mingetty
fails to "chown/chmod" /dev/tty* if /dev is mounted for read-only mode.
Good point. So, if only root can modify files in /de
Tetsuo Handa wrote:
David Newall wrote:
Tetsuo Handa wrote:
/dev needs to be writable, but this means that files on /dev might be
tampered with.
I infer that you mean /dev needs to be writable by anyone, not by just
its owner or owner and group (conventionally root/root
Tetsuo Handa wrote:
/dev needs to be writable, but this means that files on /dev might be
tampered with.
I infer that you mean /dev needs to be writable by anyone, not by just
its owner or owner and group (conventionally root/root.) This goes
against conventional wisdom, which is that /dev
Siva Prasad wrote:
I am looking at how exactly does the printf in user programs succeeds in
displaying characters to the serial console.
Is it a student assignment? This is so not the right mailing list.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
Alan Cox wrote:
without need. Not surprising since it has such a vague specific
meaning. One could say, Linux on i386 is liberally sprinkled with
"vague specific" ? sorry don't follow you.
The _p variants are a universal fixture, defined as ending with a pause,
but without specify
linux-os (Dick Johnson) wrote:
But there are some things that get set up long before
udelay() is calibrated! The interrupt controllers,
the timer, etc. You can't just substitute or you
will end up with machines that won't boot!
The initial value could be set conservatively high.
--
To unsubs
Rene Herman wrote:
This particular discussion isn't about anything in general but solely
about the delay an outb_p gives you on x86 since what is under
discussion is not using an output to port 0x80 on that platform to
generate it.
That could be true if outb_p were used only in architecture d
Rene Herman wrote:
On 11-12-07 08:40, Paul Rolland wrote:
Well, if the delay is so much unspecified, what about _reading_ port
0x80 ?
Will the delay be shorter ?
The delay is completely and fully specified in terms of the ISA/LPC clock
That would be the delay on the i386 (sic) architecture
H. Peter Anvin wrote:
David Newall wrote:
Where did the 8us delay come from? The documentation and source is
careful not to say how long the delay is. Would changing it to, say
1us, be technically wrong? Is code that requires 8us correct?
I think a single ISA bus transaction is 1 µs, so
Where did the 8us delay come from? The documentation and source is
careful not to say how long the delay is. Would changing it to, say
1us, be technically wrong? Is code that requires 8us correct?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mess
Thanos Chatziathanassiou wrote:
help
I KNOW OF PLACES, ACTIONS, AND THINGS. MOST OF MY VOCABULARY
DESCRIBES PLACES AND IS USED TO MOVE YOU THERE. TO MOVE TRY
WORDS LIKE FOREST, BUILDING, DOWNSTREAM, ENTER, EAST, WEST
NORTH, SOUTH, UP, OR DOWN. I KNOW ABOUT A FEW SPECIAL OBJECTS,
LIKE A BLACK R
Andi Kleen wrote:
Renzo also described something new (in the socket() arena): the
multi-reader, multi-writer is just not available in IP.
How is that different from a multicast group?
Good question. I don't know much about multicast IP. It's a bit new
for me. I knew it uses Martia
Kyle Moffett wrote:
On Dec 06, 2007, at 00:30:16, Renzo Davoli wrote:
AF_IPN is different. AF_IPN is the broadcast and peer-to-peer
extension of AF_UNIX. It supports communication among *user* processes.
Ok, you say it's different, but then you describe how IP unicast and
broadcast work.
R
Chris Snook wrote:
Ben Crowhurst wrote:
Has Objective-C ever been considered for kernel development?
No. Kernel programming requires what is essentially assembly language
with a lot of syntactic sugar, which C provides.
I somewhat disagree. Kernel programming requires and deserves the sam
Jan Engelhardt wrote:
On Nov 30 2007 11:20, Xavier Bestel wrote:
On Fri, 2007-11-30 at 19:09 +0900, KOSAKI Motohiro wrote:
Has Objective-C ever been considered for kernel development?
Why not C# instead ?
Why not Haskell nor Erlang instead ? :-D
I heard of
Josh Goldsmith wrote:
David: The exact command this time was a "tar jxf
linux-2.6.23.tar.bz2" as part of an emerge (gentoo). Gnu tar version
1.18 but has happened with prior versions too. I replicated it after
my post by manually untarring it on the command line and can almost
always replic
Josh Goldsmith wrote:
The problem comes when I try to untar a large file (in this case
linux-2.6.23.tar.bz2). Regardless if I kill off every other process,
eventually the oom-killer will appear and kill either the tar or the
shell.
What's the actual command you are executing?
-
To unsubscrib
Michael H. Warfield wrote:
On Sat, 2007-11-24 at 23:36 +0300, Andrey Borzenkov wrote:
I have no COM port on notebook (without port replicator which I do not have)
so COM is disabled in BIOS. No ttyS* is detected during boot (and no device
created) but I just noticed that serial modules are st
(``-_-´´) -- Fernando wrote:
I used to see stuff like this happening on my University students test servers.
Once they started doing forks inside for(;;), the server would go down.
Then they replaced the servers by vwmare machines, and now reboots are faster.
UNIX (and Linux) already has a
There seems something too-specific to PC-architecture in kernel/dma.c,
which is that DMA4 is reserved for "cascade". Perhaps it should be
reserved in architecture-specific initialisation. What do other
architectures do with that?
-
To unsubscribe from this list: send the line "unsubscribe lin
There are a couple of points I would make about your python test
harness. Your program compares real+system jiffies for both cpus; an
ideal result would be 1.00. The measurement is taken over a relatively
short period of approximately a half-second, and you kill the CPU hogs
before taking fin
Tuomo Valkonen wrote:
Well, I'm using two years old 2.6.7 kernel, because the newer
ones have become utter and total crap. (See the link in the
previous post.) It will likely be my last Linux kernel ever,
that I will use until this system becomes simply too obsolete,
at which point, if not before
ciol wrote:
* Do you think the megafreeze development model [1] and the "I don't
trust in upstream" development model are broken? (And why)
I'm new to LKML, and because this is "my first release" I've held off
saying that the development model scares me. No doubt I need to see it
through a
Jan Engelhardt wrote:
On Nov 1 2007 12:51, Peter Dolding wrote:
This is above me doing code. No matter how many fixes I do to the
core that will not fix dysfunction in the LSM section. Strict
policies on fixing the main security model will be required.
If there is no one wanting to
Richard Purdie wrote:
I've got a problem I keep running into. My computers have buggy software
which can sometimes run out of control.
Ulimit them.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Al Viro wrote:
On Fri, Oct 19, 2007 at 06:07:45AM +0930, David Newall wrote:
considerations of this whole scheme. Linux, like most Unix systems,
has never allowed hard links to directories for a number of reasons;
The claim is wrong. UNIX systems have traditionally allowed the
Jaroslav Sykora wrote:
If anybody can think of any other solution of the "redirector problem", possibly
even non-kernel based one, let me know and I'd be glad :-)
If I understand your problem, you wish to treat an archive file as if it
was a directory. Thus, in the ideal situation, you could
David Newall wrote:
David Newall wrote:
Jaroslav Sykora wrote:
Let's say we have an archive file "hello.zip" with a hello world
program source
code. We want to do this:
cat hello.zip^/hello.c
gcc hello.zip^/hello.c -o hello
etc..
Wouldn't you do
David Newall wrote:
Jaroslav Sykora wrote:
Let's say we have an archive file "hello.zip" with a hello world
program source
code. We want to do this:
cat hello.zip^/hello.c
gcc hello.zip^/hello.c -o hello
etc..
Wouldn't you do this as a user space filesystem
Jaroslav Sykora wrote:
Let's say we have an archive file "hello.zip" with a hello world program source
code. We want to do this:
cat hello.zip^/hello.c
gcc hello.zip^/hello.c -o hello
etc..
Wouldn't you do this as a user space filesystem?
-
To unsubscribe from this li
Nick Piggin wrote:
On Monday 15 October 2007 19:52, Rob Landley wrote:
On Monday 15 October 2007 8:37:44 am Nick Piggin wrote:
You really shouldn't configure
so much [swap] unless you do want the kernel to actually use it all, right?
Two words: "Software suspend". I've actually
Matthew Wilcox wrote:
You really need to get the fuck over yourself.
That is so rude. You need to learn some manners.
-
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
Russ Dill wrote:
I've been having a back and forth going for a while with my TA and OS
professor on the meaning of profile=3 and have been unable to convince
either of them. The basic question is if profile=3 is passed to kernel
with an 8MB text section, how big is the allocated profile buffer. H
[EMAIL PROTECTED] wrote:
What David meant was that "root will always have a slot" doesn't *actually*
help unless you *also* have a way to actually *spawn* such a process. In order
to do the ps, kill, and so on that you need to recover, you need to already
have either a root shell available, or a
Gustavo Chain wrote:
El Wed, 10 Oct 2007 15:14:06 +0930
David Newall <[EMAIL PROTECTED]> escribió:
Gustavo Chain wrote:
El Wed, 10 Oct 2007 11:19:27 +0930
David Newall <[EMAIL PROTECTED]> escribió:
Gustavo Chain wrote:
I think it's necessar
Gustavo Chain wrote:
El Wed, 10 Oct 2007 11:19:27 +0930
David Newall <[EMAIL PROTECTED]> escribió:
Gustavo Chain wrote:
I think it's necessary to reserve some pids to the super user.
5 must be sufficient.
Why? (Sorry if I missed something.)
¿ To prevent a
Gustavo Chain wrote:
I think it's necessary to reserve some pids to the super user.
5 must be sufficient.
Why? (Sorry if I missed something.)
Shouldn't you test for error return before the pid is allocated?
Otherwise, I think, you have to free it. Thus:
long do_fork(unsigned long clone_f
linux-os (Dick Johnson) wrote:
Just don't expect the kernel developers to authorize
its use, or show you how to do it!
Well of course you can be totally up-front and public about it. That,
after all, is the point of GPL.
-
To unsubscribe from this list: send the line "unsubscribe linux-kerne
Giuliano Gagliardi wrote:
I have a server that has to switch to different user ids, but because it does
other complex things, I would rather not have it run as root. I only need the
server to be able to switch to certain pre-defined user ids.
Why don't you use group security instead of user se
/.
I hope I haven't crossed the line between determined and annoying. I
thought we were done, but now I find meat still on this bone.
Posit a normal process having some filesystem root, and a current
working directory (pwd) lying within that root subtree. When chroot is
performed, pwd is l
Bill Davidsen wrote:
It seems there are (at least) two parts to this, one regarding
changing working directory which is clearly stated in the standards
and must work as it does, and the various issues regarding getting out
of the chroot after the cwd has entered that changed root. That second
Adrian Bunk wrote:
You claimed:
<-- snip -->
Look, when chroot was being designed, I think they intended that even root
should be unable to get out. They went so far as to say that dot-dot
wouldn't let you out; and it doesn't.
<-- snip -->
You were clearly saying that whom you call "th
Adrian Bunk wrote:
You are claiming "They went so far as to say that dot-dot wouldn't let
you out"?
I phrased it in a somewhat conversational way. The promise, which I've
now quoted from multiple sources, is expressed variously, including:
The dot-dot entry in the root directory is interp
Christer Weinigel wrote:
*spends five minutes with Google*
From the OpenBSD FAQ (an operating system most know for being really,
really focused on security):
http://www.openbsd.org/faq/faq10.html
Any application which has to assume root privileges to operate is
pointless to attempt
Alan Cox wrote:
** Plonk **
Welcome to my killfile.
Well that's a relief.
-
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://ww
Alan Cox wrote:
You quoted the standard, I merely pointed out you forgot to read it
properly. Thats your problem not mine.
How bizarre. Last email you claimed to quote the standards (but you
never did.) Your becoming an embarrassment. You were rude, and
multiple times. Please just drop
Alan,
Alan Cox wrote:
therefore it must be right. You present no reasoning to explain why the
behavior is correct; instead you use insults. I've exhausted my
tolerance for rudeness.
Well if citing standards documents at people is rudeness so be it.
Did you just tell a porky? Did you
Alan Cox wrote:
Now see I've been working on Unix systems since 1988 or so and in that
time I've learned to read the documentation properly (you haven't)
My, my, you can be unpleasant when you try. There's no need for it. As
it happens I have years of UNIX experience on you. (Newbie!)
You
Alan Cox wrote:
On Wed, 26 Sep 2007 20:04:14 +0930
David Newall <[EMAIL PROTECTED]> wrote:
Al Viro wrote:
Oh, for fsck sake... Folks, it's standard-required behaviour. Ability
to chroot() implies the ability to break out of it. Could we please
add that (along with refer
Olivier Galibert wrote:
chroot does not allow you to walk out if you're in.
You're mistaken. Or more properly, further use of chroot lets you walk
out. This really has been said before, and before, and before.
chroot("subtree"); // enter chroot
chdir("/");// now at subtree
c
Alan Cox wrote:
The dot-dot entry in the root directory is interpreted to mean the
root directory itself. Thus, dot-dot cannot be used to access files
outside the subtree rooted at the root directory.
Which is behaviour chroot preserves properly.
And yet it is the dot-dot entry whi
Al Viro wrote:
Oh, for fsck sake... Folks, it's standard-required behaviour. Ability
to chroot() implies the ability to break out of it. Could we please
add that (along with reference to SuS) to l-k FAQ and be done with that
nonsense?
I'm pretty confident that it's only standard behavior for
Kyle Moffett wrote:
David, please do tell myself and Adrian how "locking down" chroot()
the way you want will avoid letting root break out through any of the
above ways?
As has been said, there are thousands of ways to break out of a chroot.
It's just that one of them should not be that chro
Alan Cox wrote:
Good call. Though I suppose, since it's used 24x7 to aid security on
countless production servers, that security dwarfs testing. Still,
debugging, yes that's valid.
I don't suppose it makes and difference; whatever the purpose, a chroot
that doesn't change the root is buggy.
Alan Cox wrote:
On Wed, 26 Sep 2007 01:05:07 +0930
David Newall <[EMAIL PROTECTED]> wrote:
Alan Cox wrote:
Marek's loading dynamic libraries, it seems clear that the prime purpose
of chroot is to aid security. Being able to cd your way out is handy
Does it - I
Jan Engelhardt wrote:
On Sep 26 2007 01:11, David Newall wrote:
Jan Engelhardt wrote:
On Sep 26 2007 00:40, David Newall wrote:
Miloslav Semler pointed out that a root process can chdir("..") out of its
chroot.
So what? Just do this: chdir into the
Jan Engelhardt wrote:
On Sep 26 2007 00:40, David Newall wrote:
Miloslav Semler pointed out that a root process can chdir("..") out of its
chroot.
So what? Just do this: chdir into the root after chroot.
I don't think so. His exploit just got me all the way out of a c
Alan Cox wrote:
Marek's loading dynamic libraries, it seems clear that the prime purpose
of chroot is to aid security. Being able to cd your way out is handy
Does it - I can't find any evidence for that.
It seems self-evident to me. What do you think is it prime purpose?
A root use
Miloslav Semler pointed out that a root process can chdir("..") out of
its chroot. Although this is documented in the man page, it conflicts
with the essential function, which is to change the root directory of
the process. In addition to any creative uses, for example Philipp
Marek's loading
Serge E. Hallyn wrote:
Quoting David Newall ([EMAIL PROTECTED]):
Serge E. Hallyn wrote:
Quoting David Newall ([EMAIL PROTECTED]):
It might be tidy if pivot_root could be used (instead of a hack based on
a chroot bug), but it'd still be unportable.
I
Serge E. Hallyn wrote:
Quoting David Newall ([EMAIL PROTECTED]):
It might be tidy if pivot_root could be used (instead of a hack based on a
chroot bug), but it'd still be unportable.
It can.
Please re-read my previous msg.
I read it. Currently pivot_root can't be used t
Serge E. Hallyn wrote:
No reason for any new parameters to pivot_root. Just clone your mounts
namespace first.
unshare(CLONE_NEWNS);
chdir(new_dir);
pivot_root(new_dir, oldroot);
Since pivot_root actually fiddles with the vfsmnts, this is really the
only way to go about
Dave Jones wrote:
On Mon, Sep 24, 2007 at 05:56:39PM +0100, Antoine Martin wrote:
> # rm -fr tmp/chroot.broken
> rm: cannot remove directory (...)
> Same result when trying to do anything to those files chown/chmod/touch:
> "Operation not permitted"
Various files in the directories it compl
Paul Rolland "(???) wrote:
Hell, IRQ 23 is shared between libata and my modem !!!
Tried using the modem?
-
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.h
Bill Davidsen wrote:
there is no question that pivot_root is intended to have breadth for
more than one process.
I think it's clear from the man page that the original idea was to be
able to pivot_root for individual processes. The reason it doesn't do
that, the reason it affects all proces
Philipp Marek wrote:
AFAIK pivot_root() changes the / mapping for *all* processes, no?
The manual page is confusing. It even admits to being "intentionally
vague". However the goal seems clear:
"pivot_root() moves the root file system of the current process to
the directory put_ol
Philipp Marek wrote:
- User starts a small wrapper,
- that opens "/",
- chroot()s into a directory and starts fsvs.
- fsvs gets its libraries loaded
- and chroot()s back to the original system.
Isn't that what pivot_root was meant for?
-
To unsubscribe from this list: send the line "unsubscribe
Normal users cannot use chroot() themselves so they can't use chroot to
get back out
I think Bill is right, that this is to fix a method that non-root
processes can use to escape their chroot. The exploit, which is
documented in chroot(2)*, is to chdir("..") your way out. Who'd have
thought
Jacob Meuser wrote:
when I see the linux community start to take credit for works they
did not create and I see the linux community respond to warnings
that people in the community are going overboard and jeopardizing
the linux community, which we do all benefit from, with a more or
less "whateve
Robert P. J. Day wrote:
if the goal is to simply put all of the basic boot-time kernel parms
along with the module-specific ones into a single file, sorted in
alphabetical order, then i contend that this is, in fact, "silly".
Or even, "messy". There's no doubt that it should be maintained w
Robert P. J. Day wrote:
while killing some time between compiles and ridding the
kernel-parameters.txt file of out-of-date or incorrect cruft, it
occurs to me that that file is borderline valueless since it
apparently tries to document every possible boot-time parameter,
including those associa
Jan Engelhardt wrote:
On Sep 4 2007 13:53, Guilherme Vilela wrote:
I'm tryng to mount a nfs file system with the option async and run a
program that writes to the file system. The problem is that the
program keep writing even when the file system is full.
man 5 exports
async This
Eric W. Biederman wrote:
This isn't "Oh some apps are using it let's get them to stop, because
it is inconvenient". This is "No apps seems to be using this, we
keep goofing up the maintenance and no one notices, and so it is
likely a source of security problems and other nasties"
This firs
Is it actually necessary to change the license? With the dual-license,
you can keep a single code-base for both BSD and Linux platforms, which
seems terribly important to me. It'd be awful to lose that. It would
be a maintenance nightmare for BSD. Is it even possible--in real life,
I mean--
101 - 200 of 201 matches
Mail list logo
