Hello
I asked this question on kernel-newbies - no reply, hope to be luckier
here:-)
I need to collect some info on processes. One way is to read /proc
tree. But isn't there a system call (ioctl) for this? And what are those
task[], task_struct, etc. about?
Thanks
Guennadi
___
Dr. Guennadi V. Liakhovetski
Department of Applied Mathematics
University of Sheffield, U.K.
email: [email protected]
-
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/
IRC Channel: irc.openprojects.net / #kernelnewbies
Web Page: http://www.surriel.com/kernelnewbies.shtml
On Mon, 12 Mar 2001, Guennadi Liakhovetski wrote:
> Hello
>
> I asked this question on kernel-newbies - no reply, hope to be luckier
> here:-)
>
> I need to collect some info on processes. One way is to read /proc
> tree. But isn't there a system call (ioctl) for this? And what are those
Occam's Razor. Why invent new syscall when read() works?
> task[], task_struct, etc. about?
What branch? (2.0, 2.2, 2.4?)
Cheers,
Al
On Mon, 12 Mar 2001, Alexander Viro wrote:
> On Mon, 12 Mar 2001, Guennadi Liakhovetski wrote:
>
> > I need to collect some info on processes. One way is to read /proc
> > tree. But isn't there a system call (ioctl) for this? And what are those
>
> Occam's Razor. Why invent new syscall when read() works?
CPU utilisation. Each new application has to calculate it (ps, top, qps,
kps, various sysmons, procmons, etc.). Wouldn't it be worth it having a
syscall for that? Wouldn't it be more optimal?
> > task[], task_struct, etc. about?
>
> What branch? (2.0, 2.2, 2.4?)
Well, what I mean was - don't these structures contain the information I
am looking for? Let's start from the end - 2.4, then what's the difference
with 2.2 and finally 2.0?
Thanks
Guennadi
___
Dr. Guennadi V. Liakhovetski
Department of Applied Mathematics
University of Sheffield, U.K.
email: [email protected]
On Mon, Mar 12, 2001 at 09:21:37PM +0000, Guennadi Liakhovetski wrote:
> CPU utilisation. Each new application has to calculate it (ps, top, qps,
> kps, various sysmons, procmons, etc.). Wouldn't it be worth it having a
> syscall for that? Wouldn't it be more optimal?
No, it wouldn't be worth it because you're talking about
sacrificing simplicity and kernel speed in favor of functionality.
This has been know to lead to "bloat-ware". Every new syscall you
add takes just a little bit more time and space in the kernel, and
when only a small number of programs will be using it, it's really
not worth it. This time and space may not be large, but once you
get _your_ syscall added, why can't everyone else get theirs added
as well? And so, after making about a thousand specialized syscalls
standard in the kernel, you end up with IRIX (from what I've heard).
Don't even get me started about opening security holes, and
increasing code complexity. Please do a search for every other
syscall that has ever been proposed on this list, read them all
and the arguments for them, then think long and hard about why yours
should be accepted. Because I'm sure that I'm not the only person
who's going to want a good explanation as to why this syscall is
essential.
ps - CPU time is cheap, that's why they don't charge for it anymore.
Programmer time is _not_.
On Mon, 12 Mar 2001, Nathan Paul Simons wrote:
> On Mon, Mar 12, 2001 at 09:21:37PM +0000, Guennadi Liakhovetski wrote:
> > CPU utilisation. Each new application has to calculate it (ps, top, qps,
> > kps, various sysmons, procmons, etc.). Wouldn't it be worth it having a
> > syscall for that? Wouldn't it be more optimal?
The first rule of optimization: don't. I.e. optimizing something that
is not a bottleneck is pointless.
> No, it wouldn't be worth it because you're talking about
> sacrificing simplicity and kernel speed in favor of functionality.
Or, in that case, in favour of nothing. It doesn't add any functionality.
> This has been know to lead to "bloat-ware". Every new syscall you
> add takes just a little bit more time and space in the kernel, and
> when only a small number of programs will be using it, it's really
> not worth it. This time and space may not be large, but once you
> get _your_ syscall added, why can't everyone else get theirs added
> as well? And so, after making about a thousand specialized syscalls
> standard in the kernel, you end up with IRIX (from what I've heard).
In that case there is much simpler argument.
If your program checks the system load so often that converting results
from ASCII to integers takes noticable time - all you are measuring
is the load created by that program. In other words, any program that
would get any speedup from such syscall is absolutely worthless, since
the load created by measurement will drown the load you are trying
to measure.
End of story. It's not only unnecessary and tasteless, it's
useless.
Cheers,
Al
Hi Alexander, Nathan and all!
Thanks for your great answers! First of all - I was not REALLY proposing
to include this system call in the kernel - I just wanted to hear some pro
and contra - so, thanks again for your explanations! I started yesterday
sketching the required functions, will have to retreat to reading top & ps
sources, btw, apart from these 2 obvious sources, what else would you
suggest to look through for a good implementation of CPU-utilization
calculator as well as other process (multithreaded, SMP,...) statistics?
Portable (POSIX), maybe some documentation, not just sources?
Thanks
Guennadi
On Mon, 12 Mar 2001, Alexander Viro wrote:
> On Mon, 12 Mar 2001, Nathan Paul Simons wrote:
>
> > On Mon, Mar 12, 2001 at 09:21:37PM +0000, Guennadi Liakhovetski wrote:
> > > CPU utilisation. Each new application has to calculate it (ps, top, qps,
> > > kps, various sysmons, procmons, etc.). Wouldn't it be worth it having a
> > > syscall for that? Wouldn't it be more optimal?
>
> The first rule of optimization: don't. I.e. optimizing something that
> is not a bottleneck is pointless.
>
> > No, it wouldn't be worth it because you're talking about
> > sacrificing simplicity and kernel speed in favor of functionality.
>
> Or, in that case, in favour of nothing. It doesn't add any functionality.
>
> > This has been know to lead to "bloat-ware". Every new syscall you
> > add takes just a little bit more time and space in the kernel, and
> > when only a small number of programs will be using it, it's really
> > not worth it. This time and space may not be large, but once you
> > get _your_ syscall added, why can't everyone else get theirs added
> > as well? And so, after making about a thousand specialized syscalls
> > standard in the kernel, you end up with IRIX (from what I've heard).
>
> In that case there is much simpler argument.
>
> If your program checks the system load so often that converting results
> from ASCII to integers takes noticable time - all you are measuring
> is the load created by that program. In other words, any program that
> would get any speedup from such syscall is absolutely worthless, since
> the load created by measurement will drown the load you are trying
> to measure.
>
> End of story. It's not only unnecessary and tasteless, it's
> useless.
> Cheers,
> Al
>
>
___
Dr. Guennadi V. Liakhovetski
Department of Applied Mathematics
University of Sheffield, U.K.
email: [email protected]
Nathan Paul Simons writes:
> On Mon, Mar 12, 2001 at 09:21:37PM +0000, Guennadi Liakhovetski wrote:
>> CPU utilisation. Each new application has to calculate it (ps, top, qps,
>> kps, various sysmons, procmons, etc.). Wouldn't it be worth it having a
>> syscall for that? Wouldn't it be more optimal?
>
> No, it wouldn't be worth it because you're talking about
> sacrificing simplicity and kernel speed in favor of functionality.
> This has been know to lead to "bloat-ware". Every new syscall you
Bloat removal: being able to run without /proc mounted.
We don't have "kernel speed". We have kernel-mode screwing around
with text formatting.
> add takes just a little bit more time and space in the kernel, and
> when only a small number of programs will be using it, it's really
> not worth it. This time and space may not be large, but once you
> get _your_ syscall added, why can't everyone else get theirs added
> as well? And so, after making about a thousand specialized syscalls
> standard in the kernel, you end up with IRIX (from what I've heard).
This isn't just for him. Many people have wanted it.
> Don't even get me started about opening security holes, and
> increasing code complexity. Please do a search for every other
I'll get you started. Compare:
1. variable-length ASCII strings with undefined ad-hoc syntax
2. array of fixed-size (64-bit) values
> ps - CPU time is cheap, that's why they don't charge for it anymore.
> Programmer time is _not_.
Parsing costs programmer time.
On Tue, Mar 13, 2001 at 04:05:13PM -0500, Albert D. Cahalan wrote:
> Bloat removal: being able to run without /proc mounted.
>
> We don't have "kernel speed". We have kernel-mode screwing around
> with text formatting.
Or calculating things that really should be taken care of in
user space, such as CPU utilization.
> This isn't just for him. Many people have wanted it.
Yes, but how many people would actually *use* it? How many
programs out of the thousands out there would benefit from this?
If it's more than 50 widely used packages, I'd be more than happy
to see something that speeds them all up added to the kernel.
> 1. variable-length ASCII strings with undefined ad-hoc syntax
Use enumerated string functions, always.
> 2. array of fixed-size (64-bit) values
It's an array? That can still be overflowed by sloppy
programming. When it comes right down to it, I'd rather have
something that could potentially die badly be run on the user
side, rather than the kernel side.
> Parsing costs programmer time.
But it's fairly easy to do in any number of programming
languages besides C which can't be easily used in the kernel.
Not to mention parsing libraries for C that fit much better on
the user side because they would make the kernel huge and slow
if compiled into it.
Last but not least, I don't want to waste time in kernel
scanning through a list of syscalls a mile long, half of them
I don't ever use. Or having a kernel that's so big that you
can't fit it on embedded systems anymore. And once you start
adding every "nifty" syscall that comes along, that's what
will happen. So again, I say give us all a really good reason
for this syscall, or just hack it into your own kernels and
let us have our speedy, small vanilla kernels.
Nathan Paul Simons writes:
> On Tue, Mar 13, 2001 at 04:05:13PM -0500, Albert D. Cahalan wrote:
>> Bloat removal: being able to run without /proc mounted.
>>
>> We don't have "kernel speed". We have kernel-mode screwing around
>> with text formatting.
>
> Or calculating things that really should be taken care of in
> user space, such as CPU utilization.
That can not be done reliably in user space. I know this; the "top"
program used to try.
>> This isn't just for him. Many people have wanted it.
>
> Yes, but how many people would actually *use* it? How many
> programs out of the thousands out there would benefit from this?
> If it's more than 50 widely used packages, I'd be more than happy
> to see something that speeds them all up added to the kernel.
Oh please. How many programs use the mount() system call? One?
Most system calls are rarely used. This is OK.
>> 1. variable-length ASCII strings with undefined ad-hoc syntax
>
> Use enumerated string functions, always.
>
>> 2. array of fixed-size (64-bit) values
>
> It's an array? That can still be overflowed by sloppy
> programming.
No it can't. You fill it like this:
tmp[0] = p->pid;
tmp[1] = p->uid;
/* ... */
Throw in some pretty symbolic names if you like. It's effectively
a struct, but a real struct would tempt people to use non-64-bit
values. Using an array enforces uniform 64-bit usage.
Good design involves NOT tempting people to write irregular hacks.
> When it comes right down to it, I'd rather have
> something that could potentially die badly be run on the user
> side, rather than the kernel side.
Good. Thus you'd like the new system call in place of our
current pile of crud. Unfortunately the crud will need to
remain for at least a decade of transition time.
>> Parsing costs programmer time.
>
> But it's fairly easy to do in any number of programming
> languages besides C which can't be easily used in the kernel.
> Not to mention parsing libraries for C that fit much better on
> the user side because they would make the kernel huge and slow
> if compiled into it.
Huh? The kernel need not parse its own ASCII output. The kernel
natively maintains information in a binary format. The proposed
system call would not parse /proc output!!!
> Last but not least, I don't want to waste time in kernel
> scanning through a list of syscalls a mile long, half of them
> I don't ever use.
Well, tough luck. Learn to use an editor with search ability.
Even "less" and Netscape can search.
> Or having a kernel that's so big that you
> can't fit it on embedded systems anymore.
The proposed system call was implemented for an embedded system.
This allowed operation without the /proc filesystem, which is
some serious bloat.
> And once you start
> adding every "nifty" syscall that comes along, that's what
> will happen. So again, I say give us all a really good reason
> for this syscall, or just hack it into your own kernels and
> let us have our speedy, small vanilla kernels.
If you think /proc is speedy and small...
On Tue, 13 Mar 2001, Albert D. Cahalan wrote:
> Bloat removal: being able to run without /proc mounted.
>
> We don't have "kernel speed". We have kernel-mode screwing around
> with text formatting.
Sounds like you might want to maintain an external patch
for the embedded folks...
regards,
Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com.br/
Rik van Riel wrote:
>
> On Tue, 13 Mar 2001, Albert D. Cahalan wrote:
>
> > Bloat removal: being able to run without /proc mounted.
> >
> > We don't have "kernel speed". We have kernel-mode screwing around
> > with text formatting.
>
> Sounds like you might want to maintain an external patch
> for the embedded folks...
Not the embedded folks!!! The server folks laugh histerically
all times they go via ssh to a trashing busy box to see what's wrong
and then they see top or ps auxe under linux never finishing they job:
>
> regards,
>
> Rik
> --
> Virtual memory is like a game you can't win;
> However, without VM there's truly nothing to lose...
>
> http://www.surriel.com/
> http://www.conectiva.com/ http://distro.conectiva.com.br/
>
> -
> 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/
--
- phone: +49 214 8656 283
- job: eVision-Ventures AG, LEV .de (MY OPINIONS ARE MY OWN!)
- langs: de_DE.ISO8859-1, en_US, pl_PL.ISO8859-2, last ressort:
ru_RU.KOI8-R
On Tue, Mar 13, 2001 at 07:52:41PM -0300, Rik van Riel wrote:
> On Tue, 13 Mar 2001, Albert D. Cahalan wrote:
>
> > Bloat removal: being able to run without /proc mounted.
> >
> > We don't have "kernel speed". We have kernel-mode screwing around
> > with text formatting.
>
> Sounds like you might want to maintain an external patch
> for the embedded folks...
or perhaps a patch to remove the non-procfs stuff from proc - leaving
just /proc/[0-9]+ and /proc/self...
that way top/ps/ still mostly work without patches and you dont have all
the other stuff that you don't need (perhaps make a separate kernfs?).
i *am* aware of the previous flamewars over this :-) but it does appear
to me a more generally useful compromise in the anti-bloat case.
j. (who likes proc as it is now)
On Wed, 14 Mar 2001, Martin Dalecki wrote:
> Not the embedded folks!!! The server folks laugh histerically all
> times they go via ssh to a trashing busy box to see what's wrong and
> then they see top or ps auxe under linux never finishing they job:
That's a separate issue.
I guess the pagefault path should have _2_ locks.
One mmap_sem protecting read-only access to the address space
and another one for write access to the adress space (to stop
races with swapout, other page faults, ...).
At the point where the pagefault sleeps on IO, it could release
the read-only lock, so vmstat, top, etc can get the statistics
they need. Only during the time the pagefaulting code is actually
messing with the address space could it block read access (to
prevent others from seeing an inconsistent state).
regards,
Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com.br/
Rik van Riel wrote:
>
> On Wed, 14 Mar 2001, Martin Dalecki wrote:
>
> > Not the embedded folks!!! The server folks laugh histerically all
> > times they go via ssh to a trashing busy box to see what's wrong and
> > then they see top or ps auxe under linux never finishing they job:
>
> That's a separate issue.
>
> I guess the pagefault path should have _2_ locks.
>
> One mmap_sem protecting read-only access to the address space
> and another one for write access to the adress space (to stop
> races with swapout, other page faults, ...).
>
> At the point where the pagefault sleeps on IO, it could release
> the read-only lock, so vmstat, top, etc can get the statistics
> they need. Only during the time the pagefaulting code is actually
> messing with the address space could it block read access (to
> prevent others from seeing an inconsistent state).
>
Is it REALLY necessary to prevent them from seeing an inconsistent
state? Seems to me that in the total picture (i.e. system wide) they
will never see a consistent state, so why be concerned with a small
corner of the system. Let them figure it out, possibly by consistency
checks, if they care. It just seems unhealthy to demand consistency at
the cost of delays that will only make other data even more
inconsistent. And if the delay is _forever_ from a tool that may be used
to diagnose system problems... I would rather a tool that repeatedly
showed the same inconsistent state than one that hangs because it can
not get a consistent one.
George
On Wed, 14 Mar 2001, george anzinger wrote:
> Is it REALLY necessary to prevent them from seeing an
> inconsistent state? Seems to me that in the total picture (i.e.
> system wide) they will never see a consistent state, so why be
> concerned with a small corner of the system.
You're right. All we need to make sure of is that the address
space we want to print info about doesn't go away while we're
reading the stats ...
(I think ... but we'll need to look at the procfs code in more
detail)
regards,
Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com/
Rik van Riel wrote:
>
> On Wed, 14 Mar 2001, george anzinger wrote:
>
> > Is it REALLY necessary to prevent them from seeing an
> > inconsistent state? Seems to me that in the total picture (i.e.
> > system wide) they will never see a consistent state, so why be
> > concerned with a small corner of the system.
>
> You're right. All we need to make sure of is that the address
> space we want to print info about doesn't go away while we're
> reading the stats ...
>
> (I think ... but we'll need to look at the procfs code in more
> detail)
>
For what its worth:
On the last system I worked on we had a status program that maintained a
screen with interesting things such as context switches per sec, disc
i/o/sec, lan traffic/sec, ready queue length, next task (printed as
current task) and... well a whole 26X80 screen full of stuff. The
program gathered all the data by reading system tables as quickly as
possible and THEN did the formatting/ screen update. Having to deal
with pre formatted data would have a.) widened the capture window and
b.) been a real drag to reformat and move to the right screen location.
We allowed programs that had the savvy to have read only access to the
kernel area to make this as fast as possible.
George
On Mon, 12 Mar 2001, Alexander Viro wrote:
> On Mon, 12 Mar 2001, Guennadi Liakhovetski wrote:
> > I need to collect some info on processes. One way is to read /proc
> > tree. But isn't there a system call (ioctl) for this? And what are those
> Occam's Razor. Why invent new syscall when read() works?
read() doesn't really work for this purpose, it blocks way too many
times to be very annoying. When finally data arrives it's useless.
Szaka
On Wed, 14 Mar 2001, Szabolcs Szakacsits wrote:
>
> On Mon, 12 Mar 2001, Alexander Viro wrote:
> > On Mon, 12 Mar 2001, Guennadi Liakhovetski wrote:
> > > I need to collect some info on processes. One way is to read /proc
> > > tree. But isn't there a system call (ioctl) for this? And what are those
> > Occam's Razor. Why invent new syscall when read() works?
>
> read() doesn't really work for this purpose, it blocks way too many
> times to be very annoying. When finally data arrives it's useless.
Huh? Take code of your non-blocking syscall. Make it ->read() for
relevant file on /proc or wherever else you want it. See read() not
blocking...
Whether code blocks or not depends on the code, not on the calling
conventions. And definitely not on ASCII vs. binary - conversion
between these formats _is_ doable without blocking operations.
On Wed, 14 Mar 2001, Alexander Viro wrote:
> On Wed, 14 Mar 2001, Szabolcs Szakacsits wrote:
> > read() doesn't really work for this purpose, it blocks way too many
> > times to be very annoying. When finally data arrives it's useless.
> Huh? Take code of your non-blocking syscall. Make it ->read() for
> relevant file on /proc or wherever else you want it. See read() not
> blocking...
Sorry I should have quoted "blocks". Problem isn't with blocking but
*no* data, no information. In the end you can conclude you know
*nothing* what happend in the last t time interval - this can be second,
minutes even with an RT, mlocked, etc process when the load is around 0.
Szaka
On Wed, 14 Mar 2001, Szabolcs Szakacsits wrote:
>
> On Wed, 14 Mar 2001, Alexander Viro wrote:
> > On Wed, 14 Mar 2001, Szabolcs Szakacsits wrote:
> > > read() doesn't really work for this purpose, it blocks way too many
> > > times to be very annoying. When finally data arrives it's useless.
> > Huh? Take code of your non-blocking syscall. Make it ->read() for
> > relevant file on /proc or wherever else you want it. See read() not
> > blocking...
>
> Sorry I should have quoted "blocks". Problem isn't with blocking but
> *no* data, no information. In the end you can conclude you know
> *nothing* what happend in the last t time interval - this can be second,
> minutes even with an RT, mlocked, etc process when the load is around 0.
And how will a new syscall avoid the same problems you have with
read()? Again, they can share the payload code - it's a matter
of calling conventions and layout of the output. _That_ part doesn't
take long. If reading is too slow - too bad, changing the syscall
number won't help.
On Wed, 14 Mar 2001, Rik van Riel wrote:
> On Wed, 14 Mar 2001, george anzinger wrote:
>
> > Is it REALLY necessary to prevent them from seeing an
> > inconsistent state? Seems to me that in the total picture (i.e.
> > system wide) they will never see a consistent state, so why be
> > concerned with a small corner of the system.
>
> You're right.
Mmmm, I've looked at the code today and it turned out that
we're NOT right ;)
The mmap_sem is used in procfs to prevent the list of VMAs
from changing. In the page fault code it seems to be used
to prevent other page faults to happen at the same time with
the current page fault (and to prevent VMAs from changing
while a page fault is underway).
Maybe we should change the mmap_sem into a R/W semaphore ?
Since page faults seem to be the "common cause" of blocking
procfs access *and* since both page faults and procfs only
need to prevent the VMA list from changing, a read lock would
help here.
Write locks would be used in the code where we actually want
to change the VMA list and page faults would use an extra lock
to protect against each other (possibly a per-pagetable lock so
multithreaded apps can pagefault in different memory regions at
the same time ???).
regards,
Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com.br/
Hi,
On Thu, Mar 15, 2001 at 09:24:59AM -0300, Rik van Riel wrote:
> On Wed, 14 Mar 2001, Rik van Riel wrote:
> The mmap_sem is used in procfs to prevent the list of VMAs
> from changing. In the page fault code it seems to be used
> to prevent other page faults to happen at the same time with
> the current page fault (and to prevent VMAs from changing
> while a page fault is underway).
The page table spinlock should be quite sufficient to let us avoid
races in the page fault code. We've had to deal with this before
there was ever a mmap_sem anyway: in ancient times, every page fault
had to do things like check to see if the pte had changed after IO was
complete and once the BKL had been retaken. We can do the same with
the page fault spinlock without much pain.
> Maybe we should change the mmap_sem into a R/W semaphore ?
Definitely.
> Write locks would be used in the code where we actually want
> to change the VMA list and page faults would use an extra lock
> to protect against each other (possibly a per-pagetable lock
Why do we need another lock? The critical section where we do the
final update on the pte _already_ takes the page table spinlock to
avoid races against the swapper.
Cheers,
Stephen
On Fri, 16 Mar 2001, Stephen C. Tweedie wrote:
> On Thu, Mar 15, 2001 at 09:24:59AM -0300, Rik van Riel wrote:
> > On Wed, 14 Mar 2001, Rik van Riel wrote:
>
> > The mmap_sem is used in procfs to prevent the list of VMAs
> > from changing. In the page fault code it seems to be used
> > to prevent other page faults to happen at the same time with
> > the current page fault (and to prevent VMAs from changing
> > while a page fault is underway).
>
> The page table spinlock should be quite sufficient to let us avoid
> races in the page fault code.
> > Write locks would be used in the code where we actually want
> > to change the VMA list and page faults would use an extra lock
> > to protect against each other (possibly a per-pagetable lock
>
> Why do we need another lock? The critical section where we do the
> final update on the pte _already_ takes the page table spinlock to
> avoid races against the swapper.
The problem is that mmap_sem seems to be protecting the list
of VMAs, so taking _only_ the page_table_lock could let a VMA
change under us while a page fault is underway ...
Then again, I guess just making mmap_sem a R/W lock should fix
our problems ... and maybe even make it possible (in 2.5?) to
let multithreaded programs have pagefaults at the same time,
instead of having all threads queue up behind mmap_sem.
regards,
Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com.br/
Hi,
On Fri, Mar 16, 2001 at 08:50:25AM -0300, Rik van Riel wrote:
> On Fri, 16 Mar 2001, Stephen C. Tweedie wrote:
>
> > > Write locks would be used in the code where we actually want
> > > to change the VMA list and page faults would use an extra lock
> > > to protect against each other (possibly a per-pagetable lock
> >
> > Why do we need another lock? The critical section where we do the
> > final update on the pte _already_ takes the page table spinlock to
> > avoid races against the swapper.
>
> The problem is that mmap_sem seems to be protecting the list
> of VMAs, so taking _only_ the page_table_lock could let a VMA
> change under us while a page fault is underway ...
Right, I'm not suggesting removing that: making the mmap_sem
read/write is fine, but yes, we still need that semaphore. But as for
the "page faults would use an extra lock to protect against each
other" bit --- we already have another lock, the page table lock,
which can be used in this way, so ANOTHER lock should be unnecessary.
--Stephen
On Fri, 16 Mar 2001, Stephen C. Tweedie wrote:
> Right, I'm not suggesting removing that: making the mmap_sem
> read/write is fine, but yes, we still need that semaphore.
Initial patch (against 2.4.2-ac20) is available at
http://www.surriel.com/patches/
> But as for the "page faults would use an extra lock to protect against
> each other" bit --- we already have another lock, the page table lock,
> which can be used in this way, so ANOTHER lock should be unnecessary.
Tomorrow I'll take a look at the various ->nopage
functions and do_swap_page to see if these functions
would be able to take simultaneous faults at the same
address (from multiple threads). If not, either we'll
need to modify these functions, or we could add a (few?)
extra lock to prevent these functions from faulting at
the same address at the same time in multiple threads.
regards,
Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com.br/
>
> The problem is that mmap_sem seems to be protecting the list
> of VMAs, so taking _only_ the page_table_lock could let a VMA
> change under us while a page fault is underway ...
No, that can't happen.
VMA changes only happen if both the mmap_sem and the page table lock is
acquired. (check insert_vm() at the end of mm/mmap.c)
The page fault path uses the map_sem, kswaps uses page_table_lock.
<< from your patch:
--- linux-2.4.2-ac20-vm/mm/vmscan.c.orig Sat Mar 17 11:30:49 2001
+++ linux-2.4.2-ac20-vm/mm/vmscan.c Sat Mar 17 20:53:10 2001
@@ -231,6 +231,7 @@
* Find the proper vm-area after freezing the vma chain
* and ptes.
*/
+ down_read(&mm->mmap_sem);
spin_lock(&mm->page_table_lock);
>>>>
Why do you acquire the mmap semaphore in swapout_mm()? The old rule was
that kswapd should never sleep on the mmap semaphore. Isn't there a
deadlock if mmap sem is already acquired? I don't remember the details.
>
> The problem is that mmap_sem seems to be protecting the list
> of VMAs, so taking _only_ the page_table_lock could let a VMA
> change under us while a page fault is underway ...
I remember that the pmd_alloc() and pte_alloc() functions need
additional locking.
--
Manfred
On Sun, 18 Mar 2001, Rik van Riel wrote:
> On Fri, 16 Mar 2001, Stephen C. Tweedie wrote:
>
> > Right, I'm not suggesting removing that: making the mmap_sem
> > read/write is fine, but yes, we still need that semaphore.
>
> Initial patch (against 2.4.2-ac20) is available at
> http://www.surriel.com/patches/
>
> > But as for the "page faults would use an extra lock to protect against
> > each other" bit --- we already have another lock, the page table lock,
> > which can be used in this way, so ANOTHER lock should be unnecessary.
>
> Tomorrow I'll take a look at the various ->nopage
> functions and do_swap_page to see if these functions
> would be able to take simultaneous faults at the same
> address (from multiple threads). If not, either we'll
> need to modify these functions, or we could add a (few?)
> extra lock to prevent these functions from faulting at
> the same address at the same time in multiple threads.
Hi Rik,
I gave this patch a try, and the initial results are extremely encouraging.
Not only do I have vmstat (SCHED_RR) info in realtime with zero delays :))
I also have a _nice_ throughput improvement. There are some worrisome
warnings below along with the compile changes I made here, but for an
initial patch, things look pretty darn wonderful.
Cheers,
-Mike
--- ./include/linux/sched.h.org Sun Mar 18 10:20:42 2001
+++ ./include/linux/sched.h Sun Mar 18 10:27:48 2001
@@ -238,7 +238,7 @@
mm_users: ATOMIC_INIT(2), \
mm_count: ATOMIC_INIT(1), \
map_count: 1, \
- mmap_sem: __MUTEX_INITIALIZER(name.mmap_sem), \
+ mmap_sem: __RWSEM_INITIALIZER(name.mmap_sem, RW_LOCK_BIAS), \
page_table_lock: SPIN_LOCK_UNLOCKED, \
mmlist: LIST_HEAD_INIT(name.mmlist), \
}
--- ./include/linux/mm.h.org Sun Mar 18 09:56:55 2001
+++ ./include/linux/mm.h Sun Mar 18 10:27:59 2001
@@ -533,13 +533,13 @@
if (vma->vm_end - address > current->rlim[RLIMIT_STACK].rlim_cur ||
((vma->vm_mm->total_vm + grow) << PAGE_SHIFT) > current->rlim[RLIMIT_AS].rlim_cur)
return -ENOMEM;
- spin_lock(&mm->page_table_lock);
+ spin_lock(&vma->vm_mm->page_table_lock);
vma->vm_start = address;
vma->vm_pgoff -= grow;
vma->vm_mm->total_vm += grow;
if (vma->vm_flags & VM_LOCKED)
vma->vm_mm->locked_vm += grow;
- spin_unlock(&mm->page_table_lock);
+ spin_unlock(&vma->vm_mm->page_table_lock);
return 0;
}
...
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 196k freed
Adding Swap: 265064k swap-space (priority 2)
VM: Bad swap entry 00011e00
VM: Bad swap entry 00058d00
Unused swap offset entry in swap_dup 00058d00
Unused swap offset entry in swap_dup 00011e00
VM: Bad swap entry 00011e00
VM: Bad swap entry 00058d00
Unused swap offset entry in swap_dup 00058d00
VM: Bad swap entry 00058d00
Unused swap offset entry in swap_dup 00011e00
Unused swap offset entry in swap_dup 00058d00
VM: Bad swap entry 00011e00
VM: Bad swap entry 00058d00
Unused swap offset entry in swap_dup 00011e00
Unused swap offset entry in swap_dup 00058d00
VM: Bad swap entry 00011e00
VM: Bad swap entry 00058d00
Unused swap offset entry in swap_dup 008f4e00
VM: Bad swap entry 008f4e00
Unused swap offset entry in swap_dup 006ef700
Unused swap offset entry in swap_dup 008f4e00
VM: Bad swap entry 006ef700
VM: Bad swap entry 008f4e00
Unused swap offset entry in swap_dup 006ef700
Unused swap offset entry in swap_dup 008f4e00
VM: Bad swap entry 006ef700
VM: Bad swap entry 008f4e00
Unused swap offset entry in swap_dup 006ef700
Unused swap offset entry in swap_dup 008f4e00
VM: Bad swap entry 006ef700
VM: Bad swap entry 008f4e00
Unused swap offset entry in swap_dup 006ef700
Unused swap offset entry in swap_dup 008f4e00
VM: Bad swap entry 006ef700
VM: Bad swap entry 008f4e00
Unused swap offset entry in swap_dup 006ef700
Unused swap offset entry in swap_dup 008f4e00
VM: Bad swap entry 006ef700
Unused swap offset entry in swap_dup 006ef700
VM: Bad swap entry 006ef700
VM: Bad swap entry 008f4e00
Unused swap offset entry in swap_dup 006ef700
Unused swap offset entry in swap_dup 008f4e00
VM: Bad swap entry 006ef700
VM: Bad swap entry 008f4e00
Unused swap offset entry in swap_count 00011e00
Unused swap offset entry in swap_dup 006ef700
Unused swap offset entry in swap_dup 008f4e00
VM: Bad swap entry 006ef700
VM: Bad swap entry 008f4e00
Unused swap offset entry in swap_dup 008f4e00
Unused swap offset entry in swap_dup 006ef700
VM: Bad swap entry 006ef700
VM: Bad swap entry 008f4e00
Unused swap offset entry in swap_dup 006ef700
Unused swap offset entry in swap_dup 008f4e00
VM: Bad swap entry 006ef700
VM: Bad swap entry 008f4e00
Unused swap offset entry in swap_dup 006ef700
Unused swap offset entry in swap_dup 008f4e00
VM: Bad swap entry 006ef700
VM: Bad swap entry 008f4e00
Unused swap offset entry in swap_dup 006ef700
Unused swap offset entry in swap_dup 008f4e00
VM: Bad swap entry 006ef700
VM: Bad swap entry 008f4e00
Unused swap offset entry in swap_dup 006ef700
Unused swap offset entry in swap_dup 008f4e00
VM: Bad swap entry 006ef700
VM: Bad swap entry 008f4e00
Unused swap offset entry in swap_dup 008f4e00
Unused swap offset entry in swap_dup 006ef700
VM: Bad swap entry 006ef700
VM: Bad swap entry 008f4e00
Unused swap offset entry in swap_dup 006ef700
Unused swap offset entry in swap_dup 008f4e00
Unused swap offset entry in swap_dup 00011e00
VM: Bad swap entry 006ef700
VM: Bad swap entry 008f4e00
Unused swap offset entry in swap_dup 006ef700
Unused swap offset entry in swap_dup 008f4e00
VM: Bad swap entry 00011e00
Unused swap offset entry in swap_count 00011e00
VM: Bad swap entry 006ef700
VM: Bad swap entry 008f4e00
Unused swap offset entry in swap_dup 006ef700
Unused swap offset entry in swap_dup 008f4e00
VM: Bad swap entry 006ef700
VM: Bad swap entry 008f4e00
Unused swap offset entry in swap_dup 008f4e00
Unused swap offset entry in swap_dup 006ef700
On Sun, 18 Mar 2001, Mike Galbraith wrote:
> I gave this patch a try, and the initial results are extremely encouraging.
> Not only do I have vmstat (SCHED_RR) info in realtime with zero delays :))
> I also have a _nice_ throughput improvement. There are some worrisome
> warnings below along with the compile changes I made here, but for an
> initial patch, things look pretty darn wonderful.
[snip compile fixes .. integrated]
> VFS: Mounted root (ext2 filesystem) readonly.
> Freeing unused kernel memory: 196k freed
> Adding Swap: 265064k swap-space (priority 2)
> VM: Bad swap entry 00011e00
> VM: Bad swap entry 00058d00
> Unused swap offset entry in swap_dup 00058d00
> Unused swap offset entry in swap_dup 00011e00
> VM: Bad swap entry 00011e00
> VM: Bad swap entry 00058d00
Heh, I guess do_swap_page isn't too happy when multiple threads
of the same program take a page fault at the same address at the
same time.
I take it you were testing something like mysql, jvm or apache2 ?
regards,
Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com.br/
On Sun, 18 Mar 2001, Manfred Spraul wrote:
> > The problem is that mmap_sem seems to be protecting the list
> > of VMAs, so taking _only_ the page_table_lock could let a VMA
> > change under us while a page fault is underway ...
>
> No, that can't happen.
> VMA changes only happen if both the mmap_sem and the page table lock is
> acquired. (check insert_vm() at the end of mm/mmap.c)
> The page fault path uses the map_sem, kswaps uses page_table_lock.
You're right here, I missed this "little detail"...
> << from your patch:
> --- linux-2.4.2-ac20-vm/mm/vmscan.c.orig Sat Mar 17 11:30:49 2001
> +++ linux-2.4.2-ac20-vm/mm/vmscan.c Sat Mar 17 20:53:10 2001
> @@ -231,6 +231,7 @@
> * Find the proper vm-area after freezing the vma chain
> * and ptes.
> */
> + down_read(&mm->mmap_sem);
> spin_lock(&mm->page_table_lock);
> >>>>
>
> Why do you acquire the mmap semaphore in swapout_mm()? The old rule was
> that kswapd should never sleep on the mmap semaphore. Isn't there a
> deadlock if mmap sem is already acquired? I don't remember the details.
You're right, kswapd shouldn't do this. I have this removed from
my code right now...
> > The problem is that mmap_sem seems to be protecting the list
> > of VMAs, so taking _only_ the page_table_lock could let a VMA
> > change under us while a page fault is underway ...
>
> I remember that the pmd_alloc() and pte_alloc() functions need
> additional locking.
Isn't this what the page_table_lock is for ?
(too bad they're not using it...)
regards,
Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com.br/
On Sun, 18 Mar 2001, Rik van Riel wrote:
> > VFS: Mounted root (ext2 filesystem) readonly.
> > Freeing unused kernel memory: 196k freed
> > Adding Swap: 265064k swap-space (priority 2)
> > VM: Bad swap entry 00011e00
> > VM: Bad swap entry 00058d00
> > Unused swap offset entry in swap_dup 00058d00
> > Unused swap offset entry in swap_dup 00011e00
> > VM: Bad swap entry 00011e00
> > VM: Bad swap entry 00058d00
>
> Heh, I guess do_swap_page isn't too happy when multiple threads
> of the same program take a page fault at the same address at the
> same time.
>
> I take it you were testing something like mysql, jvm or apache2 ?
No, this was make -j30 bzImage. (nscd was running though...)
-Mike
On Sun, 18 Mar 2001, Mike Galbraith wrote:
> > No, this was make -j30 bzImage. (nscd was running though...)
>
> I rebooted, shut down nscd prior to testing and did 5 builds in a row
> without a single gripe. Started nscd for sixth run and instantly the
> kernel griped. Yup.. threaded apps pushing swap.
OK, I'll write some code to prevent multiple threads from
stepping all over each other when they pagefault at the
same address.
What would be the preferred method of fixing this ?
- fixing do_swap_page and all ->nopage functions
- hacking handle_mm_fault to make sure no overlapping
pagefaults will be served at the same time
regards,
Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com.br/
In article <Pine.LNX.4.21.0103181122480.13050-100000@imladris.rielhome.conectiva>,
Rik van Riel <[email protected]> wrote:
>
>OK, I'll write some code to prevent multiple threads from
>stepping all over each other when they pagefault at the
>same address.
>
>What would be the preferred method of fixing this ?
>
>- fixing do_swap_page and all ->nopage functions
There is no need to fix gthe "nopage" functions. They never see the page
table directly anyway.
So the only thing that _should_ be needed is to make sure that
do_no_page(), do_swap_page() and do_anonymous_page() will re-aquire the
mm->page_table_lock and undo their work if it turns out that the page
table entry is no longer empty..
(do_wp_page() should already be ok in this regard - it already does this
exactly because present pagetable entries can already race with kswapd.
What we're adding is that _nonpresent_ page table entries can race with
multiple invocations of concurrent page faults)
>- hacking handle_mm_fault to make sure no overlapping
> pagefaults will be served at the same time
No. The whole reason the rw_semaphores were done in the first place was
to allow page faults to happen concurrently to allow threaded
applictions to scale up even when faulting.
Linus
On Sun, 18 Mar 2001, Linus Torvalds wrote:
> In article <Pine.LNX.4.21.0103181122480.13050-100000@imladris.rielhome.conectiva>,
> Rik van Riel <[email protected]> wrote:
> >
> >OK, I'll write some code to prevent multiple threads from
> >stepping all over each other when they pagefault at the
> >same address.
> >
> >What would be the preferred method of fixing this ?
> >
> >- fixing do_swap_page and all ->nopage functions
>
> There is no need to fix gthe "nopage" functions. They never see the
> page table directly anyway.
>
> So the only thing that _should_ be needed is to make sure that
> do_no_page(), do_swap_page() and do_anonymous_page() will re-aquire
> the mm->page_table_lock and undo their work if it turns out that the
> page table entry is no longer empty..
... in which case concurrency is maximised, but there is a
possibility of doing double work...
> >- hacking handle_mm_fault to make sure no overlapping
> > pagefaults will be served at the same time
>
> No. The whole reason the rw_semaphores were done in the first place
> was to allow page faults to happen concurrently to allow threaded
> applictions to scale up even when faulting.
Indeed, having threaded apps do multiple page faults at the
same time is the main goal of this patch. However, I don't
see how it would be good for scalability to have multiple
threads fault in the same page at the same time, when they
could just wait for one of them to do the work.
Only faults for different addresses would proceed, not faults
for the same address...
regards,
Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com.br/
On Sun, 18 Mar 2001, Rik van Riel wrote:
>
> Indeed, having threaded apps do multiple page faults at the
> same time is the main goal of this patch. However, I don't
> see how it would be good for scalability to have multiple
> threads fault in the same page at the same time, when they
> could just wait for one of them to do the work.
But they will.
That's what lock_page() etc are there for - there's no need for the VM to
synchronize because we already have the synchronization primitives at a
lower level.
And there isn't any other lock that could work anyway. It's either the
whole MM or a page. There's nothing in between.
Linus
On Sun, 18 Mar 2001, Linus Torvalds wrote:
> On Sun, 18 Mar 2001, Rik van Riel wrote:
> >
> > Indeed, having threaded apps do multiple page faults at the
> > same time is the main goal of this patch. However, I don't
> > see how it would be good for scalability to have multiple
> > threads fault in the same page at the same time, when they
> > could just wait for one of them to do the work.
>
> But they will.
>
> That's what lock_page() etc are there for - there's no need for the VM
> to synchronize because we already have the synchronization primitives
> at a lower level.
Indeed. I'll go multithread the do_no_page and do_swap_page
functions tomorrow (maybe even tonight ;)).
regards,
Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com.br/
Hi,
On Sun, Mar 18, 2001 at 10:34:38AM +0100, Manfred Spraul wrote:
> > The problem is that mmap_sem seems to be protecting the list
> > of VMAs, so taking _only_ the page_table_lock could let a VMA
> > change under us while a page fault is underway ...
>
> No, that can't happen.
It can. Page faults often need to block, so they have to be able to
drop the page_table_lock. Holding the mmap_sem is all that keeps the
vma intact until the IO is complete.
Cheers,
Stephen
hi,
a friend of my asked me on how to make linux easier to use
for personal/casual win user.
i found out that one of the big problem with linux and most
other operating system is the multi-user thing.
i think, no personal computer user should know about what's
an operating system idea of a user. they just want to use
the computer, that's it.
by a personal computer i mean home pc, notebook, tablet,
pda, and communicator. only one user will use those devices,
or maybe his/her friend/family. do you think that user want
to know about user account?
from that, i also found out that it is very awkward to type
username and password every time i use my computer.
so here's a patch. i also have removed the user_struct from
my kernel, but i don't think you'd like #ifdef's.
may be it'll be good for midori too.
imel
--- sched.h Mon Apr 2 18:57:06 2001
+++ sched.h~ Tue Apr 24 17:32:33 2001
@@ -655,6 +655,12 @@
unsigned long, const char *, void *);
extern void free_irq(unsigned int, void *);
+#ifdef CONFIG_NOUSER
+#define capable(x) 1
+#define suser() 1
+#define fsuser() 1
+#else
+
/*
* This has now become a routine instead of a macro, it sets a flag if
* it returns true (to do BSD-style accounting where the process is flagged
@@ -706,6 +712,8 @@
}
return 0;
}
+
+#endif /* CONFIG_NOUSER */
/*
* Routines for handling mm_structs
diff -ur linux/Documentation/Configure.help nouser/Documentation/Configure.help
--- linux/Documentation/Configure.help Mon Apr 2 18:53:29 2001
+++ nouser/Documentation/Configure.help Tue Apr 24 18:08:49 2001
@@ -13626,6 +13626,14 @@
a work-around for a number of buggy BIOSes. Switch this option on if
your computer crashes instead of powering off properly.
+Disable Multi-user (DANGEROUS)
+CONFIG_NOUSER
+ Disable kernel multi-user support. Normally, we treat each user
+ differently, depending on his/her permissions. If you _really_
+ think that you're not going to use your computer in a hostile
+ environment and would like to cut a few bytes, say Y.
+ Most people should say N.
+
Watchdog Timer Support
CONFIG_WATCHDOG
If you say Y here (and to one of the following options) and create a
diff -ur linux/arch/i386/config.in nouser/arch/i386/config.in
--- linux/arch/i386/config.in Mon Feb 5 18:50:27 2001
+++ nouser/arch/i386/config.in Tue Apr 24 17:53:42 2001
@@ -244,6 +244,8 @@
bool ' Use real mode APM BIOS call to power off' CONFIG_APM_REAL_MODE_POWER_OFF
fi
+bool 'Disable Multi-user (DANGEROUS)' CONFIG_NOUSER
+
endmenu
source drivers/mtd/Config.in
On Tue, 24 Apr 2001 [email protected] wrote:
> a friend of my asked me on how to make linux easier to use
> for personal/casual win user.
>
> i found out that one of the big problem with linux and most
> other operating system is the multi-user thing.
What, makes it hard to write viruses for it? Awww, poor skr1pt k1dd13z...
> i think, no personal computer user should know about what's
> an operating system idea of a user. they just want to use
> the computer, that's it.
And would that "use" by any chance include access to network?
> by a personal computer i mean home pc, notebook, tablet,
> pda, and communicator. only one user will use those devices,
> or maybe his/her friend/family. do you think that user want
> to know about user account?
So let him log in as root, do everything as root and be cracked
like a bloody moron he is. Next?
> from that, i also found out that it is very awkward to type
> username and password every time i use my computer.
So break your /sbin/login.
> so here's a patch. i also have removed the user_struct from
> my kernel, but i don't think you'd like #ifdef's.
> may be it'll be good for midori too.
[snip the patch that makes all user ids equivalent to root, but
doesn't remove networking support]
What for? If they want root - give them root and be done with that.
No need to change the kernel.
You know, if you really do not understand the implications of
running everything with permissions equivalent to root - get
the hell out of any UNIX-related programming until you learn.
If you want CP/M or MacOS - you know where to find them.
On Tue, 24 Apr 2001, Alexander Viro wrote:
> What, makes it hard to write viruses for it? Awww, poor skr1pt k1dd13z...
>
>
> And would that "use" by any chance include access to network?
>
>
> So let him log in as root, do everything as root and be cracked
> like a bloody moron he is. Next?
>
come on, it's hard for me as it's hard for you. not everybody
expect a computer to be like people here thinks how a computer
should be.
think about personal devices. something like the nokia communicator.
a system security passwd is acceptable, but that's it. no those-
device-user would like to know about user account, file ownership,
etc. they just want to use it.
that also explain why win95 user doesn't want to use NT. not
because they can't afford it (belive me, here NT costs only
us$2), but additional headache isn't acceptable.
with multi-user concept, conceptually there should be an
administrator to create account, grant permission, etc.
no my sister doesn't want that. i bet there are billions of
people not willing to learn how to use a computer, they just
want to use it.
and yes, mobile devices access network.
> What for? If they want root - give them root and be done with that.
> No need to change the kernel.
>
> You know, if you really do not understand the implications of
> running everything with permissions equivalent to root - get
> the hell out of any UNIX-related programming until you learn.
>
> If you want CP/M or MacOS - you know where to find them.
so what the hell is transmeta doing with mobile linux (midori).
is it going to teach multi-user thing to tablet owners?
surely mortals expect midori to behave like their pc. lets say
on redhat, they have to login as root to access their files,
they don't even know what a root is!
lets break unix mind for a while, and give everyone a chance
to use linux.
imel
[email protected] wrote:
>
> hi,
>
> a friend of my asked me on how to make linux easier to use
> for personal/casual win user.
>
> i found out that one of the big problem with linux and most
> other operating system is the multi-user thing.
>
> i think, no personal computer user should know about what's
> an operating system idea of a user. they just want to use
> the computer, that's it.
>
> by a personal computer i mean home pc, notebook, tablet,
> pda, and communicator. only one user will use those devices,
> or maybe his/her friend/family. do you think that user want
> to know about user account?
>
> from that, i also found out that it is very awkward to type
> username and password every time i use my computer.
Sounds to me like you really don't get the whole concept of permissions
and that it's how Unix works.
Besides, why should the kernel do anythign different for you when there
are userland tools that you can use to have the system auto-login as a
specified user?
--
=====================================================================
Mohammad A. Haque http://www.haque.net/
[email protected]
"Alcohol and calculus don't mix. Project Lead
Don't drink and derive." --Unknown http://wm.themes.org/
[email protected]
=====================================================================
On Tue, 24 Apr 2001 [email protected] wrote:
>a friend of my asked me on how to make linux easier to use
>for personal/casual win user.
>
>i found out that one of the big problem with linux and most
>other operating system is the multi-user thing.
>
>i think, no personal computer user should know about what's
>an operating system idea of a user. they just want to use
>the computer, that's it.
>
>by a personal computer i mean home pc, notebook, tablet,
>pda, and communicator. only one user will use those devices,
>or maybe his/her friend/family. do you think that user want
>to know about user account?
>
>from that, i also found out that it is very awkward to type
>username and password every time i use my computer.
>so here's a patch. i also have removed the user_struct from
>my kernel, but i don't think you'd like #ifdef's.
>may be it'll be good for midori too.
trustix.co.id? hehehe.
If you don't want to login with user/password, then change your
password to "". Don't want to even do that? Then just change
/etc/inittab to invoke "login -f username" instead of mingetty or
whatever. No need at all to hack the kernel up.
Dunno why you sent the patch here or to Linus though.. The
chance of it even being looked at are about 1/2^infinity ;o)
I've got a hacked up version of mingetty that allows you to
configure autologins on tty's if you like. You're welcome to my
packages if you like just email me privately. It is useful if you
are in an environment where physical security is not a concern at
all, but network security is still a concern. I use it so I can
boot up, login once, and it fires up tty's on all consoles for
me. It can also bypass any login if you like.
----------------------------------------------------------------------
Mike A. Harris - Linux advocate - Free Software advocate
This message is copyright 2001, all rights reserved.
Views expressed are my own, not necessarily shared by my employer.
----------------------------------------------------------------------
On Tue, 24 Apr 2001 [email protected] wrote:
[snip long wankage]
Equivalent of your "patch" can be achieved by making login(1) and
friends let everyone in as root without asking password. End of
story. If you don't understand even _that_ - you don't understand
the bloody basics of the system and I certainly don't want to
deal with your code anywhere near the kernel.
On Tue, Apr 24, 2001 at 07:44:17PM +0700, [email protected] wrote:
>
> On Tue, 24 Apr 2001, Alexander Viro wrote:
> > What, makes it hard to write viruses for it? Awww, poor skr1pt k1dd13z...
> >
> > And would that "use" by any chance include access to network?
> >
> > So let him log in as root, do everything as root and be cracked
> > like a bloody moron he is. Next?
> >
>
> come on, it's hard for me as it's hard for you. not everybody
> expect a computer to be like people here thinks how a computer
> should be.
Hence, Microsoft Windows. It might not be stable, it might not be fast, it
might not do RAID, packet-filtering and SQL, but it does a job. A simple
job. To give Mum & Dad(tm) (with apologies to maddog) a chance to use a
computer.
> think about personal devices. something like the nokia communicator.
> a system security passwd is acceptable, but that's it. no those-
> device-user would like to know about user account, file ownership,
> etc. they just want to use it.
Since when, did mobile phones == computers?
> that also explain why win95 user doesn't want to use NT. not
> because they can't afford it (belive me, here NT costs only
> us$2), but additional headache isn't acceptable.
So, let them stay in Win95. They don't *need* NT.
> with multi-user concept, conceptually there should be an
> administrator to create account, grant permission, etc.
> no my sister doesn't want that. i bet there are billions of
> people not willing to learn how to use a computer, they just
> want to use it.
If your sister doesn't want that, give your sister a copy of Win95. If she
doesn't want that, she obviously wouldn't get any advantage out of Linux, as
opposed to Win95, whatsoever. Would she get a kick out of having to learn an
entirely new environment? Granted, I'm far more productive in GNOME,
Sawfish, emacs and mutt than Win95, Word and Outlook, but it takes people
time to get used to, and you'll have trouble dragging them out of
point-n-click.
> and yes, mobile devices access network.
>
> > What for? If they want root - give them root and be done with that.
> > No need to change the kernel.
> >
> > You know, if you really do not understand the implications of
> > running everything with permissions equivalent to root - get
> > the hell out of any UNIX-related programming until you learn.
> >
> > If you want CP/M or MacOS - you know where to find them.
>
> so what the hell is transmeta doing with mobile linux (midori).
> is it going to teach multi-user thing to tablet owners?
> surely mortals expect midori to behave like their pc. lets say
> on redhat, they have to login as root to access their files,
> they don't even know what a root is!
>
> lets break unix mind for a while, and give everyone a chance
> to use linux.
If you don't want multiple users, don't add them. Just be content with root,
and give her root. It has multiple user capabilities, which should be used
under all circumstances, but if you don't want something, don't use it. You
have a choice.
My $au0.02. (which is apparently just over us1c now. oh joy).
--
Daniel Stone
Linux Kernel Developer
[email protected]
On Tue, Apr 24, 2001 at 07:44:17PM +0700, [email protected] wrote:
> with multi-user concept, conceptually there should be an
> administrator to create account, grant permission, etc.
> no my sister doesn't want that. i bet there are billions of
> people not willing to learn how to use a computer, they just
> want to use it.
So they buy Macs. <- This is not a joke or a criticism. My wife is a happy
and contented ignorant mac user.
[snippage]
> so what the hell is transmeta doing with mobile linux (midori).
> is it going to teach multi-user thing to tablet owners?
> surely mortals expect midori to behave like their pc. lets say
> on redhat, they have to login as root to access their files,
> they don't even know what a root is!
>
> lets break unix mind for a while, and give everyone a chance
> to use linux.
>
If you wanted to do this, the correct place would be to alter your pam config,
but then again, if you knew the slightest thing about unix, you'd know that.
Sean
Am Dienstag, 24. April 2001 14:44 schrieb [email protected]:
> On Tue, 24 Apr 2001, Alexander Viro wrote:
> > So let him log in as root, do everything as root and be cracked
> > like a bloody moron he is. Next?
>
> come on, it's hard for me as it's hard for you. not everybody
> expect a computer to be like people here thinks how a computer
> should be.
>
> think about personal devices. something like the nokia communicator.
> a system security passwd is acceptable, but that's it. no those-
> device-user would like to know about user account, file ownership,
> etc. they just want to use it.
>
> that also explain why win95 user doesn't want to use NT. not
> because they can't afford it (belive me, here NT costs only
> us$2), but additional headache isn't acceptable.
>
> with multi-user concept, conceptually there should be an
> administrator to create account, grant permission, etc.
> no my sister doesn't want that. i bet there are billions of
> people not willing to learn how to use a computer, they just
> want to use it.
>
> and yes, mobile devices access network.
KDE2.1.1 comes with a password disabling feature. That means that you can log
in without password (you have to use KDM). For everything else (ftp, telnet,
ssh, text-console-login - whatever) you still need the password.
This is very new, KDE-versions prior to 2.1.1 don't have that feature AFAIK.
So if you've got physical access to the machine you just have to click on
your icon/name and cklick "Go!" or press Enter. It can't get much easier than
that.
I think this is a far better alternative than a single user Linux.
Greetings,
Roland
On Tue, 24 Apr 2001, Mohammad A. Haque wrote:
> [email protected] wrote:
[snip]
> Sounds to me like you really don't get the whole concept of permissions
> and that it's how Unix works.
>
> Besides, why should the kernel do anythign different for you when there
> are userland tools that you can use to have the system auto-login as a
> specified user?
With apologies to Tom Lehrer...
Hooray for the Folk Song Army,
We will show you the way.
'Cause we all hate poverty, war, and injustice,
And chords that are too hard to play.
On Tue, 24 Apr 2001 [email protected] wrote:
>
> On Tue, 24 Apr 2001, Alexander Viro wrote:
> > What, makes it hard to write viruses for it? Awww, poor skr1pt k1dd13z...
[SNIPPED..]
>
> > > And would that "use" by any chance include access to network? >
>
> >
> > So let him log in as root, do everything as root and be cracked
> > like a bloody moron he is. Next?
> >
>
> come on, it's hard for me as it's hard for you. not everybody
> expect a computer to be like people here thinks how a computer
> should be.
>
> think about personal devices. something like the nokia communicator.
> a system security passwd is acceptable, but that's it. no those-
> device-user would like to know about user account, file ownership,
> etc. they just want to use it.
>
[SNIPPED...]
You are on the wrong list. You don't modify the kernel to make
a "single-user" machine. You modify the password file in /etc/passwd.
Until you know, and completely understand this, you will be laughed at.
When an interactive process is started, /bin/login gets the new
process information from the /etc/passwd file just before it gets
overwritten (exec) by the shell shown in that same password file.
If you want your accounts to have root privs, you set the UID and
GID fields in the password file to 0 and 0 respectively. I would
not suggest that you connect your computer to a network if you
do this.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
>
> trustix.co.id? hehehe.
>
> If you don't want to login with user/password, then change your
> password to "". Don't want to even do that? Then just change
> /etc/inittab to invoke "login -f username" instead of mingetty or
> whatever. No need at all to hack the kernel up.
>
> Dunno why you sent the patch here or to Linus though.. The
> chance of it even being looked at are about 1/2^infinity ;o)
:-) Great.
You and Alex are right - I agree that this is a complete moronism.
But, what I should say to the network security, is that AFAIK in the most
of linux distributions the standard daemons (httpd, sendmail) are run as
root! Having multi-user system or not! Why? For only listening to a port
<1024? Is there any elegant solution?
Tomas
On Tue, 24 Apr 2001, Daniel Stone wrote:
> Hence, Microsoft Windows. It might not be stable, it might not be fast, it
> might not do RAID, packet-filtering and SQL, but it does a job. A simple
> job. To give Mum & Dad(tm) (with apologies to maddog) a chance to use a
> computer.
>
>
> Since when, did mobile phones == computers?
read the news! i'm programming nokia 9210 with c++, is that
computer enough?
i bet if you programmed one, you'd wish you have posix
interface.
>
> > that also explain why win95 user doesn't want to use NT. not
> > because they can't afford it (belive me, here NT costs only
> > us$2), but additional headache isn't acceptable.
>
> So, let them stay in Win95. They don't *need* NT.
and how's stability, speed, etc. they read. is there a linux
advocate around here?
> If your sister doesn't want that, give your sister a copy of Win95. If she
> doesn't want that, she obviously wouldn't get any advantage out of Linux, as
> opposed to Win95, whatsoever. Would she get a kick out of having to learn an
> entirely new environment? Granted, I'm far more productive in GNOME,
> Sawfish, emacs and mutt than Win95, Word and Outlook, but it takes people
> time to get used to, and you'll have trouble dragging them out of
> point-n-click.
okay, it wouldn't cost me. but it surely easier if everybody used
linux, so i could put my ext2 disk everywhere i want.
hey, it's obvious that it's not for a server!
i try to point out a problem for people not on this list, don't
work around that problem.
imel
On Tue, 24 Apr 2001, Tomas Telensky wrote:
> :-) Great.
> You and Alex are right - I agree that this is a complete moronism.
>
> But, what I should say to the network security, is that AFAIK in the most
> of linux distributions the standard daemons (httpd, sendmail) are run as
> root! Having multi-user system or not! Why? For only listening to a port
> <1024? Is there any elegant solution?
If your distro is runnign httpd as root you may want to give them a nice
swift kick in the behind. By default apache is configured to run as
nobody.
Dunno about sendmail.
Correct. <1024 requires root to bind to the port.
--
=====================================================================
Mohammad A. Haque http://www.haque.net/
[email protected]
"Alcohol and calculus don't mix. Project Lead
Don't drink and derive." --Unknown http://wm.themes.org/
[email protected]
=====================================================================
On Tue, 24 Apr 2001, Richard B. Johnson wrote:
> You are on the wrong list. You don't modify the kernel to make
> a "single-user" machine. You modify the password file in /etc/passwd.
> Until you know, and completely understand this, you will be laughed at.
>
> When an interactive process is started, /bin/login gets the new
> process information from the /etc/passwd file just before it gets
> overwritten (exec) by the shell shown in that same password file.
>
> If you want your accounts to have root privs, you set the UID and
> GID fields in the password file to 0 and 0 respectively. I would
> not suggest that you connect your computer to a network if you
> do this.
thank you very much fyi.
if just you tried to understand it a little further:
i didn't change all uid/gid to 0!
why? so with that radical patch, users will still have
uid/gid so programs know the user's profile.
if everyone had 0/0 uid/gid, pine will open /var/spool/mail/root,
etc.
imel
On Tue, 24 Apr 2001, Tomas Telensky wrote:
> of linux distributions the standard daemons (httpd, sendmail) are run as
> root! Having multi-user system or not! Why? For only listening to a port
> <1024? Is there any elegant solution?
Sendmail is old. Consider it as a remnant of times when network was
more... friendly. Security considerations were mostly ignored - and
not only by sendmail. It used to be choke-full of holes. They were
essentially debugged out of it in late 90s. It seems to be more or
less OK these days, but it's full of old cruft. And splitting the
thing into reasonable parts and leaving them with minaml privileges
they need is large and painful work.
There are alternatives (e.g. exim, or two unmentionable ones) that are
cleaner. Besides, there are some, erm, half-promises that next major
release of sendmail may be a big cleanup. Hell knows what will come out
of that.
On Tue, 24 Apr 2001, Mohammad A. Haque wrote:
> Correct. <1024 requires root to bind to the port.
... And nothing says that it should be done by daemon itself.
On Tue, Apr 24, 2001 at 08:27:56PM +0700, [email protected] wrote:
> On Tue, 24 Apr 2001, Daniel Stone wrote:
> > Hence, Microsoft Windows. It might not be stable, it might not be fast, it
> > might not do RAID, packet-filtering and SQL, but it does a job. A simple
> > job. To give Mum & Dad(tm) (with apologies to maddog) a chance to use a
> > computer.
> >
> >
> > Since when, did mobile phones == computers?
>
> read the news! i'm programming nokia 9210 with c++, is that
> computer enough?
Aah. I see. Where was this? I never saw it.
> i bet if you programmed one, you'd wish you have posix
> interface.
That may be so, so hack up your own OS. It's a MOBILE PHONE, it needs to be
absolutely *rock solid*. Look at the 5110, that's just about perfect. The
7110, on the other hand ...
> > > that also explain why win95 user doesn't want to use NT. not
> > > because they can't afford it (belive me, here NT costs only
> > > us$2), but additional headache isn't acceptable.
> >
> > So, let them stay in Win95. They don't *need* NT.
>
> and how's stability, speed, etc. they read. is there a linux
> advocate around here?
There are Linux advocates, but I'd say most of us are sane enough to use the
right-tool-for-the-job approach. And UNIX on a phone is pure overkill.
> > If your sister doesn't want that, give your sister a copy of Win95. If she
> > doesn't want that, she obviously wouldn't get any advantage out of Linux, as
> > opposed to Win95, whatsoever. Would she get a kick out of having to learn an
> > entirely new environment? Granted, I'm far more productive in GNOME,
> > Sawfish, emacs and mutt than Win95, Word and Outlook, but it takes people
> > time to get used to, and you'll have trouble dragging them out of
> > point-n-click.
>
> okay, it wouldn't cost me. but it surely easier if everybody used
> linux, so i could put my ext2 disk everywhere i want.
>
> hey, it's obvious that it's not for a server!
> i try to point out a problem for people not on this list, don't
> work around that problem.
Your sister won't notice much advantage. Linux on a workstation actually has
*disadvantages* (unfamiliar interface, unintuitive same, etc), as opposed to
'Doze on a workstation. Sure it's more stable, and the tiniest bit faster,
but what's that really matter to your sister, if she can't even figure out
how to use it?
-d, who owns a 7110 and can lock it solid, or get it to do funny resetting
tricks, at least once every 2 days
--
Daniel Stone
Linux Kernel Developer
[email protected]
On Tue, 24 Apr 2001 [email protected] wrote:
> okay, it wouldn't cost me. but it surely easier if everybody used
> linux, so i could put my ext2 disk everywhere i want.
>
> hey, it's obvious that it's not for a server!
> i try to point out a problem for people not on this list, don't
> work around that problem.
Man, do you like not search for software or someting?
1) There exists a ext2 driver for Win9x
2) You are NOT trying to point out or solve a problem. You're just
trying to force something you think is right in your own little world
into the kernel. Had you searched around, you'd see that this 'problem'
as you call it has been addressed.
--
=====================================================================
Mohammad A. Haque http://www.haque.net/
[email protected]
"Alcohol and calculus don't mix. Project Lead
Don't drink and derive." --Unknown http://wm.themes.org/
[email protected]
=====================================================================
On Tue, 24 Apr 2001, Roland Seuhs wrote:
>> with multi-user concept, conceptually there should be an
>> administrator to create account, grant permission, etc.
>> no my sister doesn't want that. i bet there are billions of
>> people not willing to learn how to use a computer, they just
>> want to use it.
>>
>> and yes, mobile devices access network.
>
>KDE2.1.1 comes with a password disabling feature. That means that you can log
>in without password (you have to use KDM). For everything else (ftp, telnet,
>ssh, text-console-login - whatever) you still need the password.
ftp://people.redhat.com/mharris/hacks/mingetty
This allows you to do:
5:2345:respawn:/sbin/mingetty --autologin=mharris tty5
in /etc/inittab at boot time. The only problem with it is if you
upgrade and mingetty gets upgraded the standard mingetty doesn't
grok --autologin so it explodes and respawns until init kills it.
I'm rewriting it to use a config file instead, and might possibly
change the name if Florian doesn't mind.
----------------------------------------------------------------------
Mike A. Harris - Linux advocate - Free Software advocate
This message is copyright 2001, all rights reserved.
Views expressed are my own, not necessarily shared by my employer.
----------------------------------------------------------------------
On Tue, 24 Apr 2001, Alexander Viro wrote:
>
>
> On Tue, 24 Apr 2001, Tomas Telensky wrote:
>
> > of linux distributions the standard daemons (httpd, sendmail) are run as
> > root! Having multi-user system or not! Why? For only listening to a port
> > <1024? Is there any elegant solution?
>
> Sendmail is old. Consider it as a remnant of times when network was
> more... friendly. Security considerations were mostly ignored - and
> not only by sendmail. It used to be choke-full of holes. They were
> essentially debugged out of it in late 90s. It seems to be more or
> less OK these days, but it's full of old cruft. And splitting the
> thing into reasonable parts and leaving them with minaml privileges
> they need is large and painful work.
Thanks for the comment. And why not just let it listen to 25 and then
being run as uid=nobody, gid=mail?
Tomas
>
> There are alternatives (e.g. exim, or two unmentionable ones) that are
> cleaner. Besides, there are some, erm, half-promises that next major
> release of sendmail may be a big cleanup. Hell knows what will come out
> of that.
>
> so what the hell is transmeta doing with mobile linux (midori).
> is it going to teach multi-user thing to tablet owners?
Thats you problem. Distinguish the OS from the user interface.
> surely mortals expect midori to behave like their pc. lets say
> on redhat, they have to login as root to access their files,
> they don't even know what a root is!
Even my digital tv box has multiple users. The fact you cannot figure out how
to make your UI present that to the end user in a suitable manner is not
the kernels problem. Get a real UI designer
On Tue, 24 Apr 2001, Daniel Stone wrote:
> Aah. I see. Where was this? I never saw it.
psst, it's a proto.
> That may be so, so hack up your own OS. It's a MOBILE PHONE, it needs to be
> absolutely *rock solid*. Look at the 5110, that's just about perfect. The
> 7110, on the other hand ...
mobile phone to you! already, people has put linux on pdas.
> There are Linux advocates, but I'd say most of us are sane enough to use the
> right-tool-for-the-job approach. And UNIX on a phone is pure overkill.
problem is you guys are to unix-centric, try to be user-centric a little.
it's not like it ruins everything. that patch basically do something
like allowing access to port <1024 to everybody, someone just need
to bring a notebook to get passwd from nis.
multi-user security is useless at home as physical access is there.
imel
On Tue, 24 Apr 2001, Tomas Telensky wrote:
> Thanks for the comment. And why not just let it listen to 25 and then
> being run as uid=nobody, gid=mail?
Handling of .forward, for one thing. Or pipe aliases, or...
None of this stuff is unsolvable (e.g. handling of .forward belongs to
MDA, not MTA), but changing that will break existing setups.
On Tue, 24 Apr 2001, Alan Cox wrote:
> > so what the hell is transmeta doing with mobile linux (midori).
> > is it going to teach multi-user thing to tablet owners?
>
> Thats you problem. Distinguish the OS from the user interface.
sigh. is that mean the little thing had to do capable() check
each time it access something?
> Even my digital tv box has multiple users. The fact you cannot figure out how
> to make your UI present that to the end user in a suitable manner is not
> the kernels problem. Get a real UI designer
if it's useful, it's okay. if not, what is it doing there?
imel
On Tue, Apr 24, 2001 at 09:04:02PM +0700, [email protected] wrote:
>
>
What's with all these blank lines? Everywhere!
> On Tue, 24 Apr 2001, Daniel Stone wrote:
> > Aah. I see. Where was this? I never saw it.
>
> psst, it's a proto.
Right-o. In the news, you say. Hrm.
> > That may be so, so hack up your own OS. It's a MOBILE PHONE, it needs to be
> > absolutely *rock solid*. Look at the 5110, that's just about perfect. The
> > 7110, on the other hand ...
>
> mobile phone to you! already, people has put linux on pdas.
True, but I don't see what's so l33t about having bash on an Agenda, except
for, say, the novelty value of opening it up and writing "date" to get the
date in UNIX format, when someone asks you the time.
> > There are Linux advocates, but I'd say most of us are sane enough to use the
> > right-tool-for-the-job approach. And UNIX on a phone is pure overkill.
>
> problem is you guys are to unix-centric, try to be user-centric a little.
We're too UNIX-centric, yet you're the one trying to put UNIX on a phone?
Come on ...
Al Viro made some excellent points there. If you want to run single-user,
hack /sbin/login. Hack /sbin/init. But it's not the kernel's job, what you
do.
> it's not like it ruins everything. that patch basically do something
> like allowing access to port <1024 to everybody, someone just need
> to bring a notebook to get passwd from nis.
> multi-user security is useless at home as physical access is there.
Well, not really, because what if I run single-user, but I also need to get
in from home? So, everyone who connects, gets in? What if I run BIND, and
forget to update before an exploit? Whoops, there goes my entire system,
exploited like that. Single-user is absolutely stupid, IMNSHO. Unless, of
course, if you're using something that will *never* be connected, like a
watch. In a rabbithole. A rabbithole which is B2 secure.
--
Daniel Stone
Linux Kernel Developer
[email protected]
> On Tue, 24 Apr 2001, Mohammad A. Haque wrote:
> > Correct. <1024 requires root to bind to the port.
> ... And nothing says that it should be done by daemon itself.
Or that you shouldnt let inetd do it for you
And that you shouldn't drop the capabilities except that bind
It is possible to implement the entire mail system without anything running
as root but xinetd.
On Tue, 24 Apr 2001, Alan Cox wrote:
> > On Tue, 24 Apr 2001, Mohammad A. Haque wrote:
> > > Correct. <1024 requires root to bind to the port.
> > ... And nothing says that it should be done by daemon itself.
>
> Or that you shouldnt let inetd do it for you
> And that you shouldn't drop the capabilities except that bind
>
> It is possible to implement the entire mail system without anything running
> as root but xinetd.
You want an MDA with elevated privileges, though...
On Tue, 24 Apr 2001 [email protected] wrote:
>> Even my digital tv box has multiple users. The fact you cannot figure out how
>> to make your UI present that to the end user in a suitable manner is not
>> the kernels problem. Get a real UI designer
>
>if it's useful, it's okay. if not, what is it doing there?
Serving it's purpose? ;o)
Here is a useful command for you to add to your toolkit:
chmod -R 777 /
GPL of course. ;o)
----------------------------------------------------------------------
Mike A. Harris - Linux advocate - Free Software advocate
This message is copyright 2001, all rights reserved.
Views expressed are my own, not necessarily shared by my employer.
----------------------------------------------------------------------
On Tue, Apr 24, 2001 at 03:18:11PM +0100, Alan Cox wrote:
> > On Tue, 24 Apr 2001, Mohammad A. Haque wrote:
> > > Correct. <1024 requires root to bind to the port.
> > ... And nothing says that it should be done by daemon itself.
>
> Or that you shouldnt let inetd do it for you
> And that you shouldn't drop the capabilities except that bind
>
> It is possible to implement the entire mail system without anything running
> as root but xinetd.
Or even without xinetd. Just use local port forwarding eg 2525 -> 25, and
use port 2525 as SMTP port in your MTA. I've succeed to setup such a
configuration.
--
--[ G?bor L?n?rt ]---[ Vivendi Telecom Hungary ]---------[ [email protected] ]--
U have 8 bit comp or chip of them and it's unused or to be sold? Call me!
-------[ +36 30 2270823 ]------> LGB <-----[ Linux/UNIX/8bit 4ever ]-----
> > Even my digital tv box has multiple users. The fact you cannot figure out how
> > to make your UI present that to the end user in a suitable manner is not
> > the kernels problem. Get a real UI designer
>
> if it's useful, it's okay. if not, what is it doing there?
For one it allowing you to build enough of a security model to prevent your
phone user from deleting critical system files by accident. Something
incredibly basic that I cannot believe anyone could overlook
Take a look why my Digital TV has multiple users
- It can charge pay per view films to multiple accounts
(think about multiple SIM cards)
- It remembers personal barriers (so I can require
passwords to watch adult rated films for example)
(For a phone think about call barring - set the phone user
and loan it for calls home only to children)
- It remembers preferences. (Currently only useful for junk
sky interactive stuff like email)
(think about multiple email accounts)
And it has a perfectly sane UI for all of this. In fact most people have
probably never realised their set top box even has the concept of users in it
because they've never set more than one up.
Another reason your device needs good security models is that if I can't store
digital credit card data safely on it, its a dead product line soon. If it
can't do internet its an ex product.
How do you plan to do internet without a security model in your OS. How are you
going to protect credit card data from web browser bugs. How are you going to
protect that data from sms parsing bugs ?
How do you plan to deal with synchronizing data between multiple systems when
you have no user model ?
The questions you should be asking are not 'Why do I need a security model' they
are 'Is the model provided good enough'.
Alan
> > It is possible to implement the entire mail system without anything running
> > as root but xinetd.
>
> You want an MDA with elevated privileges, though...
What role requires priviledge once the port is open ?
DNS lookup does not
Spooling to disk does not
Accepting a connection from a client does not
Doing peercred auth with a client does not
Copying spool articles matching the peercred to the client does not
Alan
On Tue, 24 Apr 2001, Alan Cox wrote:
> > > It is possible to implement the entire mail system without anything running
> > > as root but xinetd.
> >
> > You want an MDA with elevated privileges, though...
^
> What role requires priviledge once the port is open ?
.forward handling may, depending on how much do you want to put into it.
On Tue, Apr 24, 2001 at 03:37:34PM +0100, Alan Cox wrote:
> What role requires priviledge once the port is open ?
>
> DNS lookup does not
> Spooling to disk does not
> Accepting a connection from a client does not
> Doing peercred auth with a client does not
> Copying spool articles matching the peercred to the client does not
Running procmail as the user who is to receive the email for local mail
delivery as running it with gid mail (for eg) would allow one user to
modify another's mail.
(just a thought - the above's valid with sendmail at least)
--
CaT ([email protected]) *** Jenna has joined the channel.
<cat> speaking of mental giants..
<Jenna> me, a giant, bullshit
<Jenna> And i'm not mental
- An IRC session, 20/12/2000
On Tue, 24 Apr 2001, Alan Cox wrote:
> > On Tue, 24 Apr 2001, Mohammad A. Haque wrote:
> > > Correct. <1024 requires root to bind to the port.
> > ... And nothing says that it should be done by daemon itself.
>
> Or that you shouldnt let inetd do it for you
> And that you shouldn't drop the capabilities except that bind
>
> It is possible to implement the entire mail system without anything running
> as root but xinetd.
>
Qmail does exactly this afik.
I've always found the root < 1024 to be quite limmited and find myself
wishing I could assign permissions based on ip/port.
Gerhard
--
Gerhard Mack
[email protected]
<>< As a computer I find your faith in technology amusing.
On Tue, 24 Apr 2001, [iso-8859-2] G?bor L?n?rt wrote:
>
> Or even without xinetd. Just use local port forwarding eg 2525 -> 25, and
This is more like 25 -> 2525 :-)
> use port 2525 as SMTP port in your MTA. I've succeed to setup such a
> configuration.
This requires you to ensure that your MTA is started first on that
port...Might be difficult to achieve reliably in an automatic way
without root privileges :-(
mailuser@foo% /etc/rc.d/init.d/sendmail stop
badguy@foo% ./suck 2525
mailuser@foo% /etc/rc.d/init.d/sendmail start
...
Le 25 Apr 2001 00:06:57 +1000, Daniel Stone a ?crit :
> > problem is you guys are to unix-centric, try to be user-centric a little.
>
> We're too UNIX-centric, yet you're the one trying to put UNIX on a phone?
> Come on ...
Hey ! We already put uClinux on a phone ! Full-fledge linux is not far,
beware !
Cheers,
Xav
On Tue, Apr 24, 2001 at 04:49:57PM +0200, Pjotr Kourzanoff wrote:
> On Tue, 24 Apr 2001, [iso-8859-2] G?bor L?n?rt wrote:
> >
> > Or even without xinetd. Just use local port forwarding eg 2525 -> 25, and
>
> This is more like 25 -> 2525 :-)
OK, that was a hard night for me, I need some sleeeeeep :)
> > use port 2525 as SMTP port in your MTA. I've succeed to setup such a
> > configuration.
>
> This requires you to ensure that your MTA is started first on that
> port...Might be difficult to achieve reliably in an automatic way
> without root privileges :-(
>
> mailuser@foo% /etc/rc.d/init.d/sendmail stop
> badguy@foo% ./suck 2525
> mailuser@foo% /etc/rc.d/init.d/sendmail start
Yes, you're right. But this is a mail server without any user on it
(even users are authenticated from LDAP).
--
--[ G?bor L?n?rt ]---[ Vivendi Telecom Hungary ]---------[ [email protected] ]--
U have 8 bit comp or chip of them and it's unused or to be sold? Call me!
-------[ +36 30 2270823 ]------> LGB <-----[ Linux/UNIX/8bit 4ever ]-----
> > Copying spool articles matching the peercred to the client does not
>
> Running procmail as the user who is to receive the email for local mail
> delivery as running it with gid mail (for eg) would allow one user to
> modify another's mail.
What is this gid mail crap ? You don't need priviledge. You get the mail by
asking the daemon for it. procmail needs no priviledge either if it is done
right.
You just need to think about the security models in the right way. Linux gives
you the ability to do authenticated uid/gid checking over a socket connection.
That is an incredibly powerful model for real compartmentalisation.
Alan
> I've always found the root < 1024 to be quite limmited and find myself
> wishing I could assign permissions based on ip/port.
Its been done. Search for 'sockfs' I believe it was called.
On Tue, Apr 24, 2001 at 04:49:57PM +0200, Pjotr Kourzanoff wrote:
> > use port 2525 as SMTP port in your MTA. I've succeed to setup such a
> > configuration.
>
> This requires you to ensure that your MTA is started first on that
> port...Might be difficult to achieve reliably in an automatic way
> without root privileges :-(
>
> mailuser@foo% /etc/rc.d/init.d/sendmail stop
> badguy@foo% ./suck 2525
> mailuser@foo% /etc/rc.d/init.d/sendmail start
Not necessarily. While I have no yet used the feature, iptables
permits firewalling on userid. I presume this includes wether or
not a program can listen on a port, right? (and all the other
fun things).
If so then all you'd have to do is deny external access to port 2525
and only permit mailuser to listen etc on it and you're set.
--
CaT ([email protected]) *** Jenna has joined the channel.
<cat> speaking of mental giants..
<Jenna> me, a giant, bullshit
<Jenna> And i'm not mental
- An IRC session, 20/12/2000
Alan Cox wrote:
> > so what the hell is transmeta doing with mobile linux (midori).
> > is it going to teach multi-user thing to tablet owners?
>
> Thats you problem. Distinguish the OS from the user interface.
>
> > surely mortals expect midori to behave like their pc. lets say
> > on redhat, they have to login as root to access their files,
> > they don't even know what a root is!
>
> Even my digital tv box has multiple users. The fact you cannot figure out how
> to make your UI present that to the end user in a suitable manner is not
> the kernels problem. Get a real UI designer.
Quote of the day:
Never engage in a battle of wits with an idiot; they will bring
you down to their level, then beat you with experience.
Cheers!
Jeremy
On Tue, Apr 24, 2001 at 03:59:28PM +0100, Alan Cox wrote:
> What is this gid mail crap ? You don't need priviledge. You get the mail by
> asking the daemon for it. procmail needs no priviledge either if it is done
> right.
>
> You just need to think about the security models in the right way. Linux gives
> you the ability to do authenticated uid/gid checking over a socket connection.
> That is an incredibly powerful model for real compartmentalisation.
Ok. My experience isn't all that great so I may well be missing something
here. But what?
1. email -> sendmail
2. sendmail figures out what it has to do with it. turns out it's deliver
it locally for user blah
3. sendmail starts procmail so that it delivers the email.
4. procmail goes through the recepie list for user blah and eventually
delivers the email (one way or another)
Now, in order for step 4 to be done safely, procmail should be running
as the user it's meant to deliver the mail for. for this to happen
sendmail needs to start it as that user in step 3 and to do that it
needs extra privs, above and beyond that of a normal user.
Now as I said, I'm not a UNIX God[tm] and so I may well be missing something
vital. If so, what is it? This sounds like something that would be way
useful to learn. :)
--
CaT ([email protected]) *** Jenna has joined the channel.
<cat> speaking of mental giants..
<Jenna> me, a giant, bullshit
<Jenna> And i'm not mental
- An IRC session, 20/12/2000
Tomas Telensky <[email protected]>
> On Tue, 24 Apr 2001, Alexander Viro wrote:
> > On Tue, 24 Apr 2001, Tomas Telensky wrote:
> >
> > > of linux distributions the standard daemons (httpd, sendmail) are run as
> > > root! Having multi-user system or not! Why? For only listening to a port
> > > <1024? Is there any elegant solution?
> >
> > Sendmail is old. Consider it as a remnant of times when network was
> > more... friendly. Security considerations were mostly ignored - and
> > not only by sendmail. It used to be choke-full of holes. They were
> > essentially debugged out of it in late 90s. It seems to be more or
> > less OK these days, but it's full of old cruft. And splitting the
> > thing into reasonable parts and leaving them with minaml privileges
> > they need is large and painful work.
Actually, if you view sendmail as being an expert system it is very
cutting edge :-) It can identify a user from very skimpy data if it
is allowed to (fuzzy matching user names). It identifies local hosts
(with FQDN or partial name, or only host name).
> Thanks for the comment. And why not just let it listen to 25 and then
> being run as uid=nobody, gid=mail?
Because then everybodys mail would be owned by user "nobody".
There are some ways to do this, but they are unreliable.
1. If the users mail is delivered to /var/mail/<username>; then the
file /var/mail/<username> must always exist.
This requires ALL MUAs to truncate the file.
Some MUAs use file existance to determine if there is new mail.
If it doesn't exist, then no new mail... ever.
2. sendmail will not be able to create the /var/mail/<username> mail box.
3. sendmail will not be able to process forwarding mail.
User nobody should not be able to read files in users home
directory... .forward files are private to the user...
4. sendmail will not be able to process user mail filters (same problem
as forwarding).
Note: these filters are applied on receipt of mail (saves time and
disk space since the filter can discard mail immediately or put it
in appropriate folders immediately).
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [email protected]
Any opinions expressed are solely my own.
On Wed, 25 Apr 2001, CaT wrote:
> On Tue, Apr 24, 2001 at 04:49:57PM +0200, Pjotr Kourzanoff wrote:
> > > use port 2525 as SMTP port in your MTA. I've succeed to setup such a
> > > configuration.
> >
> > This requires you to ensure that your MTA is started first on that
> > port...Might be difficult to achieve reliably in an automatic way
> > without root privileges :-(
> >
> > mailuser@foo% /etc/rc.d/init.d/sendmail stop
> > badguy@foo% ./suck 2525
> > mailuser@foo% /etc/rc.d/init.d/sendmail start
>
> Not necessarily. While I have no yet used the feature, iptables
> permits firewalling on userid. I presume this includes wether or
man iptables.
> not a program can listen on a port, right? (and all the other
> fun things).
>
> If so then all you'd have to do is deny external access to port 2525
> and only permit mailuser to listen etc on it and you're set.
For this to work, you need to hack up iptables on the mail server
itself as -m owner only works for locally generated packets. And
even then ./suck will receive on 2525 but will not be able to reply.
> 1. email -> sendmail
> 2. sendmail figures out what it has to do with it. turns out it's deliver
...
> Now, in order for step 4 to be done safely, procmail should be running
> as the user it's meant to deliver the mail for. for this to happen
> sendmail needs to start it as that user in step 3 and to do that it
> needs extra privs, above and beyond that of a normal user.
email -> sendmail
sendmail 'its local' -> spool
user:
get_mail | procmail
mutt
The mail server doesnt need to run procmail. If you wanted to run mail batches
through on a regular basis you can use cron for it, or leave a daemon running
On Tue, Apr 24, 2001 at 04:53:10PM +0100, Alan Cox wrote:
> > 1. email -> sendmail
> > 2. sendmail figures out what it has to do with it. turns out it's deliver
> ...
>
> > Now, in order for step 4 to be done safely, procmail should be running
> > as the user it's meant to deliver the mail for. for this to happen
> > sendmail needs to start it as that user in step 3 and to do that it
> > needs extra privs, above and beyond that of a normal user.
>
> email -> sendmail
> sendmail 'its local' -> spool
Isn't this a good thing to have spam filtered out before it will be
written in spool?
Alex Riesen
> think about personal devices. something like the nokia communicator.
> a system security passwd is acceptable, but that's it. no those-
> device-user would like to know about user account, file ownership,
> etc. they just want to use it.
If you are making a personal device, like an "appliance", there is no
need to patch the kernel - at least not to remove the concept of users.
Instead, change your startup scripts. In that situation, you will have
a custom application that is automatically started at boot and runs with
enough privileges to do whatever it needs.
The user never sees a login prompt. If you want a Windows-95 style
setup for Linux, you can do that too - but don't run as root! Just have
the startup scripts auto-login as an unprivileged user.
Kernel patches to do this are completely unnecessary, and a bad idea.
Permissions are important to have on an appliance-like system, as they
can be used to help prevent the end user from accessing the guts of the
system which should be off limits for them.
--------- Received message begins Here ---------
>
> > 1. email -> sendmail
> > 2. sendmail figures out what it has to do with it. turns out it's deliver
> ...
>
> > Now, in order for step 4 to be done safely, procmail should be running
> > as the user it's meant to deliver the mail for. for this to happen
> > sendmail needs to start it as that user in step 3 and to do that it
> > needs extra privs, above and beyond that of a normal user.
>
> email -> sendmail
> sendmail 'its local' -> spool
>
> user:
> get_mail | procmail
> mutt
>
> The mail server doesnt need to run procmail. If you wanted to run mail batches
> through on a regular basis you can use cron for it, or leave a daemon running
And get_mail must have elevated privileges to search for the users mail...
or sendmail must have already switched user on reciept to put it in the
users inbox which also requires privleges...
And an additional daemon (owned by the user) is yet another attack point...
Cron could be used to batch message handling... as long as it runs before
the users quota is used up. This becomes the same as using IMAP or fetchmail
to download it.
It's much more efficent to process each mail as it arrives.
All this does is move the program that requires privileges to somewhere
else. It doesn't eliminate it.
Granted, sendmail could use a better implementation of a security model.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [email protected]
Any opinions expressed are solely my own.
"Thinking out of the box," you don't need to modify the kernel or the
userland utilities to make Linux automatically launch a dedicated terminal
for embedded applications. All you need to do is look at the file
/etc/inittab and read the man pages for this file. For console access, you
merely make a shell the first program launched, and you specify RESPAWN as
the restart type so that if the shell crashes you get your shell back. The
invocation may need to be put in a wrapper so that standard input, standard
output, and standard error are set properly, as are the environment variables.
The security model of Unix need not be sacrificed. The wrapper can set the
user ID to a default non-zero user so that there is more security than the
all-root solution that others have suggested. For administrative duties,
the user would use su (and appropriate password) to acquire the appropriate
permissions.
Back when Unix was first given out by Bell Labs in the '70s, several Bell
people wrote papers describing exactly how to do this sort of thing in
Version 7. In the thirty years since the technique was described, the
underlying structure -- init/getty/login -- hasn't changed. I suspect that
many people here haven't explored the power of inittab, especially given
the discussion about dying daemons a few months back and how the problem
was solved in the beginning and the solution ignored today. (For those of
you interested, you might want to check the archives for the tangent in the
OOMkiller discussion.)
(Sorry, I've not found those papers on-line, and my copies were lost about
seven moves ago.)
Satch
At 06:44 PM 4/24/01 +0700, [email protected] wrote:
>hi,
>
>a friend of my asked me on how to make linux easier to use
>for personal/casual win user.
>
>i found out that one of the big problem with linux and most
>other operating system is the multi-user thing.
>
>i think, no personal computer user should know about what's
>an operating system idea of a user. they just want to use
>the computer, that's it.
>
>by a personal computer i mean home pc, notebook, tablet,
>pda, and communicator. only one user will use those devices,
>or maybe his/her friend/family. do you think that user want
>to know about user account?
>
>from that, i also found out that it is very awkward to type
>username and password every time i use my computer.
>so here's a patch. i also have removed the user_struct from
>my kernel, but i don't think you'd like #ifdef's.
>may be it'll be good for midori too.
>
>
> imel
>
>
>
>--- sched.h Mon Apr 2 18:57:06 2001
>+++ sched.h~ Tue Apr 24 17:32:33 2001
>@@ -655,6 +655,12 @@
> unsigned long, const char *, void *);
> extern void free_irq(unsigned int, void *);
>
>+#ifdef CONFIG_NOUSER
>+#define capable(x) 1
>+#define suser() 1
>+#define fsuser() 1
>+#else
>+
> /*
> * This has now become a routine instead of a macro, it sets a flag if
> * it returns true (to do BSD-style accounting where the process is flagged
>@@ -706,6 +712,8 @@
> }
> return 0;
> }
>+
>+#endif /* CONFIG_NOUSER */
>
> /*
> * Routines for handling mm_structs
>
>diff -ur linux/Documentation/Configure.help
>nouser/Documentation/Configure.help
>--- linux/Documentation/Configure.help Mon Apr 2 18:53:29 2001
>+++ nouser/Documentation/Configure.help Tue Apr 24 18:08:49 2001
>@@ -13626,6 +13626,14 @@
> a work-around for a number of buggy BIOSes. Switch this option on if
> your computer crashes instead of powering off properly.
>
>+Disable Multi-user (DANGEROUS)
>+CONFIG_NOUSER
>+ Disable kernel multi-user support. Normally, we treat each user
>+ differently, depending on his/her permissions. If you _really_
>+ think that you're not going to use your computer in a hostile
>+ environment and would like to cut a few bytes, say Y.
>+ Most people should say N.
>+
> Watchdog Timer Support
> CONFIG_WATCHDOG
> If you say Y here (and to one of the following options) and create a
>diff -ur linux/arch/i386/config.in nouser/arch/i386/config.in
>--- linux/arch/i386/config.in Mon Feb 5 18:50:27 2001
>+++ nouser/arch/i386/config.in Tue Apr 24 17:53:42 2001
>@@ -244,6 +244,8 @@
> bool ' Use real mode APM BIOS call to power off'
> CONFIG_APM_REAL_MODE_POWER_OFF
> fi
>
>+bool 'Disable Multi-user (DANGEROUS)' CONFIG_NOUSER
>+
> endmenu
>
> source drivers/mtd/Config.in
>
>-
>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/
> And get_mail must have elevated privileges to search for the users mail...
> or sendmail must have already switched user on reciept to put it in the
> users inbox which also requires privleges...
No. Think instead of blindly following existing implementation
socket(AF_UNIX, SOCK_STREAM, 0);
connect("/var/run/mailservice");
write("GIMMEMYMAIL\n");
read("200 CATCH..");
read(all my mail)
The daemon needs no priviledge. The client needs no priviledge. The
PEERCRED authentication on AF_UNIX sockets does the work. I can even pass you
back the file handle of the mailbox if I was using an old style non database
indexed mail spool.
> It's much more efficent to process each mail as it arrives.
You are doing a lot more exec() calls that way. If you get enough mail
to make spool space an issue you want a daemon.
Alan
Hello,
On Tue, 24 Apr 2001, Alan Cox wrote:
> > Now, in order for step 4 to be done safely, procmail should be running
> > as the user it's meant to deliver the mail for. for this to happen
> > sendmail needs to start it as that user in step 3 and to do that it
> > needs extra privs, above and beyond that of a normal user.
>
> email -> sendmail
> sendmail 'its local' -> spool
>
> user:
> get_mail | procmail
> mutt
>
> The mail server doesnt need to run procmail. If you wanted to run mail batches
> through on a regular basis you can use cron for it, or leave a daemon running
Oh, well, cron is just another suid program.
This example would just be the ideal scenario for posix- or novell-style
ACLs in the filesystem.
You run the MDA/MTA under some mailerdaemon uid. And then a user can
explicitly give this daemon read access to .procmail etc. You can also
give the MTA (and nobody else) write access to /var/spool/mail. The MDA
then gives the specifical user full access to the spoolfile when creating
it, or adding mail to it. And the user can fetch his mail and truncate or
delete the file just as he and his software is used to.
There are much more things with ACLs, especially in workgroup environments
(That's why I loved the old Novel server in our university), but they
never got into the kernel. And as far as I (as a non-hacker) understand,
the fields reserved for this feature were dropped for the large file
support, so we may never see ACLs.
Gru?,
Markus
--
| Gluecklich ist, wer vergisst, was nicht aus ihm geworden ist.
+---------------------------------------. ,---------------->
http://www.uni-ulm.de/~s_mschab/ \ /
mailto:[email protected] \_/
On Tue, Apr 24, 2001 at 07:44:17PM +0700, [email protected] wrote:
> come on, it's hard for me as it's hard for you. not everybody
> expect a computer to be like people here thinks how a computer
> should be.
I'm sorry, you're looking at the problem the wrong way around.
Its not a kernel problem, but a user space problem.
> think about personal devices. something like the nokia communicator.
> a system security passwd is acceptable, but that's it. no those-
> device-user would like to know about user account, file ownership,
> etc. they just want to use it.
If you do everything as one user, then you are effectively in a
single-user mode. Just make sure that the user owns all the files
that they might need.
Your change still doesn't get rid of the /bin/login program - you still
have to do that, so why not do it anyway?
Also, I know of no personal device that gives you access to system
software (which is effectively what giving a user 'root' access
gives you). How many users do you know who can copy the firmware
in their phone or organiser?
> that also explain why win95 user doesn't want to use NT. not
> because they can't afford it (belive me, here NT costs only
> us$2), but additional headache isn't acceptable.
I'm sorry, that's a different problem, and _even_ Windows 95 and 98
has a "User Logon". Only if you use the system in a single user mode
does it not have a logon. You can do the same with Linux again
without making kernel modifications.
I'd like to point out that RedHat have thought about this, and they
have some of the infrastructure in there to automatically log you
on at boot time in (within X).
As I say, this is a user space issue, and distributions are addressing
it adequately.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
[email protected] wrote:
> hi,
>
> a friend of my asked me on how to make linux easier to use
> for personal/casual win user.
>
>
> from that, i also found out that it is very awkward to type
> username and password every time i use my computer.
> so here's a patch.
Neet hack, but maybe the kernel isn't the best
place to do this -
For instance, you can simply use the KDE 2.1.1 login
manager, with the current kernel intact, to automatically
log in and start the X session of a specific user, upon
entering runlevel 5 -
Might this not be a better direction?
cu
jjs
> that also explain why win95 user doesn't want to use NT. not
> because they can't afford it (belive me, here NT costs only
> us$2), but additional headache isn't acceptable.
I'm going to speak from experience:
My mother, who is the biggest windoze fan on the face of the universe, got
fed up with win98 and decided to move to win2k. The hole "multi-user" thing
doesn't bother her in the slightest. She has a non-admin account for
herself "karen".
You want a better example?
My little cousin is not much into computers but he uses one enough to check
mail, surf the web etc... Like many win98 users he was re-installing it
about once a month. He finally got so fed up he asked me to install Linux
for him!
He is now very happy. He doesn't care about the fact that he has to type
in his user name. He even doesn't know any shell commands. He would
probably actually get concerned if he had to use root always because that
would reveal the same problems that he was having with win98.
There's a lot of things you can do to make Linux easier for newbies. None
of them involve hacking the kernel. Have you tried Linux-Mandrake 8.0 yet?
--
Garett Spencley
On Tue, 24 Apr 2001, Tomas Telensky wrote:
>
> But, what I should say to the network security, is that AFAIK in the most
> of linux distributions the standard daemons (httpd, sendmail) are run as
> root! Having multi-user system or not! Why? For only listening to a port
> <1024? Is there any elegant solution?
>
httpd as root ? that's what i call a clueless network admin.
sendmail has an OBSOLETE design. Use a good MTA like qmail. Exim or
smail are ok, but they're still "sendmailish".
David G?mez
"The question of whether computers can think is just like the question of
whether submarines can swim." -- Edsger W. Dijkstra
On Tue, Apr 24, 2001 at 11:38:01PM +1000, Daniel Stone wrote:
> And UNIX on a phone is pure overkill.
Quit being a naysayer. UNIX on a PDA is a wet dream.
On Tue, Apr 24, 2001 at 05:01:18PM -0700, Aaron Lehmann wrote:
> On Tue, Apr 24, 2001 at 11:38:01PM +1000, Daniel Stone wrote:
> > And UNIX on a phone is pure overkill.
>
> Quit being a naysayer. UNIX on a PDA is a wet dream.
What real value does it have, apart from the geek "look at me, I'm using
bash" value?
--
Daniel Stone
Linux Kernel Developer
[email protected]
> > Quit being a naysayer. UNIX on a PDA is a wet dream.
> What real value does it have, apart from the geek "look at me, I'm using
> bash" value?
It means I can do anything on my ipaq I can do anywhere else. I can run
multiple apps at a time. I can run X11. I can run the palm emulator even ;)
Its the same reason Linux is valuable on an S/390 mainframe. Its a common pool
of apps, environments and tools. Anything your PC can do, my ipaq can do.
Alan
On Wed, Apr 25, 2001 at 10:07:48AM +1000, Daniel Stone wrote:
> What real value does it have, apart from the geek "look at me, I'm using
> bash" value?
I don't really want to get into it at the moment, but imagine hacking
netfilter without lugging a laptop around. PDA's are sleek and cool,
and using UNIX on them lets you write shell scripts to sort your
addresses and stuff like that. Basically it's everything that's cool
about Unix as a workstation OS scaled down to PDA-size.
At 5:01 PM -0700 2001-04-24, Aaron Lehmann wrote:
>On Tue, Apr 24, 2001 at 11:38:01PM +1000, Daniel Stone wrote:
>> And UNIX on a phone is pure overkill.
>
>Quit being a naysayer. UNIX on a PDA is a wet dream.
http://www.agendacomputing.com/ (not that the reviews have been very kind)
--
/Jonathan Lundell.
On Tue, Apr 24, 2001 at 05:20:27PM -0700, Aaron Lehmann wrote:
> On Wed, Apr 25, 2001 at 10:07:48AM +1000, Daniel Stone wrote:
> > What real value does it have, apart from the geek "look at me, I'm using
> > bash" value?
>
> I don't really want to get into it at the moment, but imagine hacking
> netfilter without lugging a laptop around. PDA's are sleek and cool,
> and using UNIX on them lets you write shell scripts to sort your
> addresses and stuff like that. Basically it's everything that's cool
> about Unix as a workstation OS scaled down to PDA-size.
True, but then imagine trying to hack C (no, that's a CURLY BRACE, and a
tab! not space! you just broke my makefiles! aargh!), and compiling
Netfilter (it takes HOW MANY hours to compile init/main.c?!?) on a PDA.
Hrmz.
--
Daniel Stone
Linux Kernel Developer
[email protected]
On Wed, Apr 25, 2001 at 10:32:46AM +1000, Daniel Stone wrote:
> True, but then imagine trying to hack C (no, that's a CURLY BRACE, and a
> tab! not space! you just broke my makefiles! aargh!), and compiling
> Netfilter (it takes HOW MANY hours to compile init/main.c?!?) on a PDA.
> Hrmz.
I didn't say it was practical. But those PDA's are getting downright
speedy. Much faster than UNIX workstations from days of old.
Input is a big problem, but we'll leave that to technology (speech?
microkeyboards?)
On Wed, Apr 25, 2001 at 01:16:03AM +0100, Alan Cox wrote:
> > > Quit being a naysayer. UNIX on a PDA is a wet dream.
> > What real value does it have, apart from the geek "look at me, I'm using
> > bash" value?
>
> It means I can do anything on my ipaq I can do anywhere else. I can run
> multiple apps at a time. I can run X11. I can run the palm emulator even ;)
How long does it take you to write "date"? Plus, aren't you content with
IRCing on your *phone*? ;)
> Its the same reason Linux is valuable on an S/390 mainframe. Its a common pool
> of apps, environments and tools. Anything your PC can do, my ipaq can do.
OK. "time make bzImage". Of course, mine's really slow (and I will consider
myself publically humiliated if my only Linux machine is beaten on a kernel
compile by an iPAQ). I 'spose, if it only goes into suspend, the ability to
write "uptime" on it constitutes a walking penis extension after a while?
--
Daniel Stone
Linux Kernel Developer
[email protected]
On Tue, Apr 24, 2001 at 05:35:10PM -0700, Aaron Lehmann wrote:
> On Wed, Apr 25, 2001 at 10:32:46AM +1000, Daniel Stone wrote:
> > True, but then imagine trying to hack C (no, that's a CURLY BRACE, and a
> > tab! not space! you just broke my makefiles! aargh!), and compiling
> > Netfilter (it takes HOW MANY hours to compile init/main.c?!?) on a PDA.
> > Hrmz.
>
> I didn't say it was practical. But those PDA's are getting downright
> speedy. Much faster than UNIX workstations from days of old.
Please, oh please, tell me my machine would beat it on a "time make
bzImage". Else I'll do something really stupid. Like, get one for my
workstation and feel the improvement ;)
> Input is a big problem, but we'll leave that to technology (speech?
> microkeyboards?)
Aye - difference between space and tab. Broken Makefiles, anyone?
--
Daniel Stone
Linux Kernel Developer
[email protected]
On Wed, 25 Apr 2001, Daniel Stone wrote:
> OK. "time make bzImage". Of course, mine's really slow (and I will consider
> myself publically humiliated if my only Linux machine is beaten on a kernel
> compile by an iPAQ). I 'spose, if it only goes into suspend, the ability to
> write "uptime" on it constitutes a walking penis extension after a while?
When I first started I compiled my linux kernels on a 386 dx with 8 mb ram
heh. I think a lot of the current PDAs are faster.
Gerhard
--
Gerhard Mack
[email protected]
<>< As a computer I find your faith in technology amusing.
In article <[email protected]>,
Alan Cox <[email protected]> wrote:
>> > Quit being a naysayer. UNIX on a PDA is a wet dream.
>> What real value does it have, apart from the geek "look at me, I'm using
>> bash" value?
>
>It means I can do anything on my ipaq I can do anywhere else. I can run
>multiple apps at a time. I can run X11. I can run the palm emulator even ;)
>
>Its the same reason Linux is valuable on an S/390 mainframe. Its a common pool
>of apps, environments and tools. Anything your PC can do, my ipaq can do.
Or even if you only ever use the builtin apps on your Linux PDA, it means you
didn't subsidize Microsoft.
--
__O
Lineo - For Embedded Linux Solutions _-\<,_
PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68
Stuart Lynne <[email protected]> http://www.fireplug.net 604-461-7532
On Tue, 24 Apr 2001, Aaron Lehmann did have cause to say:
> On Wed, Apr 25, 2001 at 10:07:48AM +1000, Daniel Stone wrote:
> > What real value does it have, apart from the geek "look at me, I'm using
> > bash" value?
>
> I don't really want to get into it at the moment, but imagine hacking
> netfilter without lugging a laptop around. PDA's are sleek and cool,
> and using UNIX on them lets you write shell scripts to sort your
> addresses and stuff like that. Basically it's everything that's cool
> about Unix as a workstation OS scaled down to PDA-size.
Two (not quite exclusive ;) ..) points:
First, most pda's have apps like telnet/ssh/etc available. (And even more
specific apps are available for various uses - I recall a palm pilot app
that talked to cisco gear and gave a nice gui for 90% of the config, plus
a terminal for the rest.)
And second, I agree that there are some great advantages to small linux
(my ipaq runs linux, and my barely larger libretto is a full debian
mirror) but all of these (even pocketlinux, which is basically not linux)
work with the concept of multiple users. Whether for profiles or for
system vs user, they all use it. This patch is trash.
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1 [http://www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a-->? C++++$ ULBS*++++$ P- L+++>+++++
E--- W+++ N+@ o+>$ K? w--->+++++ O- M V-- PS+() PE Y+@ PGP++() t
5--- X-- R tv+@ b++++>$ DI++++ D++(+++) G++ e* h(-)* r++ y++
------END GEEK CODE BLOCK------
Tomas Telensky wrote:
<snip>
>But, what I should say to the network security, is that AFAIK in the most
>of linux distributions the standard daemons (httpd, sendmail) are run as
>root! Having multi-user system or not! Why? For only listening to a port
><1024? Is there any elegant solution?
>
Yes, most daemons have the ability to switch user ID once they have
bound tho the port. Additionally, support is starting to show up for
capabilities. I know that ProFTPD has support. Now, assuming it is
running on a newer kernel, it never needs to be root, because it has
been granted the capability to open a low port. Even if it is cracked,
it cannot do other things like . . . insert a kernel module, . . .
overwrite /etc/passwd . . . . . etc
-b
--
Three things are certain:
Death, taxes, and lost data
Guess which has occurred.
- - - - - - - - - - - - - - - - - - - -
Patched Micro$oft servers are secure today . . . but tomorrow is another story!
[email protected] wrote:
>
>
>On Tue, 24 Apr 2001, Daniel Stone wrote:
>
>>Hence, Microsoft Windows. It might not be stable, it might not be fast, it
>>might not do RAID, packet-filtering and SQL, but it does a job. A simple
>>job. To give Mum & Dad(tm) (with apologies to maddog) a chance to use a
>>computer.
>>
>>
>>Since when, did mobile phones == computers?
>>
>
>read the news! i'm programming nokia 9210 with c++, is that
>computer enough?
>
If that is what this discussion is about, you may just be better off
with a custom program to run instead of init. Have you ever booted with
init=/bin/bash? Notice how it doesn't require a password . . . Use your
own program here and you have no need of butchering the kernel. Be much
easier to maintain as well.
-b
--
Three things are certain:
Death, taxes, and lost data
Guess which has occurred.
- - - - - - - - - - - - - - - - - - - -
Patched Micro$oft servers are secure today . . . but tomorrow is another story!
On Tue, 24 Apr 2001, Aaron Lehmann wrote:
>Date: Tue, 24 Apr 2001 17:01:18 -0700
>From: Aaron Lehmann <[email protected]>
>To: [email protected], Daniel Stone <[email protected]>,
> Alexander Viro <[email protected]>, [email protected]
>Content-Type: text/plain; charset=us-ascii
>Subject: Re: [PATCH] Single user linux
>
>On Tue, Apr 24, 2001 at 11:38:01PM +1000, Daniel Stone wrote:
>> And UNIX on a phone is pure overkill.
>
>Quit being a naysayer. UNIX on a PDA is a wet dream.
No, actually, it is a reality:
http://www.agendacomputing.com
----------------------------------------------------------------------
Mike A. Harris - Linux advocate - Free Software advocate
This message is copyright 2001, all rights reserved.
Views expressed are my own, not necessarily shared by my employer.
----------------------------------------------------------------------
"If it isn't source, it isn't software." -- NASA
On Tue, 24 Apr 2001, Jonathan Lundell wrote:
>Date: Tue, 24 Apr 2001 17:26:29 -0700
>From: Jonathan Lundell <[email protected]>
>To: Aaron Lehmann <[email protected]>
>Cc: [email protected]
>Content-Type: text/plain; charset="us-ascii"
>Subject: Re: [PATCH] Single user linux
>
>At 5:01 PM -0700 2001-04-24, Aaron Lehmann wrote:
>>On Tue, Apr 24, 2001 at 11:38:01PM +1000, Daniel Stone wrote:
>>> And UNIX on a phone is pure overkill.
>>
>>Quit being a naysayer. UNIX on a PDA is a wet dream.
>
>http://www.agendacomputing.com/ (not that the reviews have been very kind)
Nor has an official product been released. Reviewing hardware
and software in open development model before it is officially
stamped "final release" is unfair to say the least. I follow the
agenda list and it is a nice piece of hardware and the software
is coming along quite nicely. I've heard mostly good stuff about
it so far, although it is not a consumer level product yet - it
is a developers product, for people ready to fire up emacs and
start coding.
----------------------------------------------------------------------
Mike A. Harris - Linux advocate - Free Software advocate
This message is copyright 2001, all rights reserved.
Views expressed are my own, not necessarily shared by my employer.
----------------------------------------------------------------------
"If it isn't source, it isn't software." -- NASA
> True, but then imagine trying to hack C (no, that's a CURLY BRACE, and a
> tab! not space! you just broke my makefiles! aargh!), and compiling
> Netfilter (it takes HOW MANY hours to compile init/main.c?!?) on a PDA.
Usual misguided assumptions
1. Many PDA's have a keyboard
2. The ipaq has an optional fold up keyboard
3. Modern PDA's have 200Mhz processors and XScale will see some of them
hitting 600MHz+
On 2001.04.25 02:52:22 +0200 Gerhard Mack wrote:
> On Wed, 25 Apr 2001, Daniel Stone wrote:
>
> > OK. "time make bzImage". Of course, mine's really slow (and I will
> consider
> > myself publically humiliated if my only Linux machine is beaten on a
> kernel
> > compile by an iPAQ). I 'spose, if it only goes into suspend, the
> ability to
> > write "uptime" on it constitutes a walking penis extension after a
> while?
>
> When I first started I compiled my linux kernels on a 386 dx with 8 mb
> ram
> heh. I think a lot of the current PDAs are faster.
Who says it needs to compile? Who says it needs software installed? Who
says it needs to run the software itself?
First of all, if linux will make it on a PDA, I'm sure there will be
prepackaged stuff. But more important, a PDA doesn't need other software
installed to have a function. It can function as a remote X-terminal
connected to a big linux X-server somewhere else which runs the software.
In that case, the speed of the PDA is no longer a problem and you have a
cute little and simple fully-featured X-window system. It's just a bit
small. Now if we get something like IBM's speach recognition system and it
works a bit, or we make our own speach recognition system, this can serve
very well for simple things like adding points to your agenda, writing
e-mail. But for just reading your mail or your agenda, you don't need more
than to press some buttons and read the screen. And for pressing the
buttons you really don't need anything else than a touchscreen or some (1?
2?) buttons on the PDA...
And for using linux as a command-line too on a PDA - we'll need something
to make input easier, like Aaron Lehman suggested in another e-mail
(keyboard, speach recognition).
--
Ronald Bultje
On Wed, Apr 25, 2001 at 08:45:25AM +0100, Alan Cox wrote:
> > True, but then imagine trying to hack C (no, that's a CURLY BRACE, and a
> > tab! not space! you just broke my makefiles! aargh!), and compiling
> > Netfilter (it takes HOW MANY hours to compile init/main.c?!?) on a PDA.
>
> Usual misguided assumptions
>
> 1. Many PDA's have a keyboard
> 2. The ipaq has an optional fold up keyboard
> 3. Modern PDA's have 200Mhz processors and XScale will see some of them
> hitting 600MHz+
I stand corrected. Too broke to get one, but corrected nevertheless.
(I've only seen the agenda in action, and it seemed a lot of time writing
"date" for relatively little action - the date).
--
Daniel Stone
[email protected]
[email protected] wrote:
> thank you very much fyi.
> if just you tried to understand it a little further:
> i didn't change all uid/gid to 0!
>
> why? so with that radical patch, users will still have
> uid/gid so programs know the user's profile.
>
> if everyone had 0/0 uid/gid, pine will open /var/spool/mail/root,
> etc.
So you want multi-user to distinguish users, but no login sequence
with typing of passwords & username.
You can have all that without changing the kernel!
Linux distributions runs things like login and getty by default,
but you don't have to do that.
If you run linux on a device not perceived as a computer,
consider this:
1. Run whatever daemons you need as root or under daemon usernames,
depending on what privileges they need.
2. Run the user interface program (X or whatever) as a user,
not root. No, they don't need a password for that. Just
start it from inittab, with a wrapper program that su's to the
appropriate user without asking for passwords.
3. If the user really need root for anything, such as changing
device configuration, use a suid configuration program. No
password needed with that approach. You probably want
a configuration program anyway as your "dumb" users probably
don't know how to edit files in /etc anyway. Making
it suid is no extra work.
Now you have both the security of linux and the ease of use of a
password-less system. Part of linux stability comes from the
fact that ordinary users cannot do anything. Crashing the
machine is easy as root, but an appliance user don't need
to be root for normal use. And the special cases which need
it can be handled by suid programs that cannot do "anything",
just the purpose they are written for.
Linux is very configurable even without patching the kernel.
A general rule is that no kernel patches is accepted for
problems that are easily solvable with simple programs.
Helge Hafting
[email protected]. writes:
> i didn't change all uid/gid to 0!
>
> why? so with that radical patch, users will still have
> uid/gid so programs know the user's profile.
So you:
1. broke security (OK, fine...)
2. didn't remove all the support for security
It would be far more interesting to rip out all trace of security.
That would include the kernel memory access checking, parts of the
task struct, filesystem and VFS code, and surely much more.
Then you can try to show a measurable performance difference.
first, i think i owe you guys apology for didn't make myself
clear, which is going harder if you irritated.
even my subject went wrong, as the patch isn't really about
single user (which confuse some people).
for those who didn't read that patch, i #define capable(),
suser(), and fsuser() to 1. the implication is all users
will have root capabilities.
then i tried to bring up the single user thing to hear
opinions (not flames). and by that, i actually didn't mean
to have users share the same uid/gid 0. i know somebody
will need to differentiate user.
so when everybody suggested playing with login, getty, etc.
i know you have got the wrong idea. if i wanted to play
on user space, i'd rather use capset() to set all users
capability to "all cap". that's the perfect equivalent.
so the user space solution (capset()) works, but then came
the idea to optimize away. that's what blow everybody up.
don't get me wrong, i always agree with rik farrow when he
wrote in ;login: that we should build software with security
in mind.
but i also hate bloat. lets not go to arm devices, how about
a notebook. it's a personal thing, naturally to people who
doesn't know about computer, personal doesn't go with multi
user. by that i mean user with different capabilities, not
different persons.
i haven't catch up with all my mails, but my response to
some:
- linux is stable not only because security.
- linux was designed for multi-user, dos f.eks. is designed
for personal use, so does epoc, palmos, mac, etc.
- i even use plan9 with kfs restrictions disabled sometimes,
cause i don't have cpu server, auth server, etc.
- with that patch, people will still have authentication.
so ssh for example, will still prevent illegal access, if
you had an exploit you're screwed up anyway.
sure httpd will give permission to everybody to browse
a computer, but i don't think a notebook need to run it.
so i guess i deserve opinions instead of flames. the
approach is from personal use, not the usual server use.
if you think a server setup is best for all use just say so,
i'm listening.
> It would be far more interesting to rip out all trace of
security.
> That would include the kernel memory access checking,
parts of the
> task struct, filesystem and VFS code, and surely much
more.
i did say it clearly that i have other changes which i know
won't be a clean patch (too many #ifdefs). f.eks. on my
computer i didn't even compile user.c in, i don't have
user_struct. filesystem and vfs code are affected by that
patch already. memory access is important of course.
> Then you can try to show a measurable performance
difference.
nah, performance was never my consideration. i do save about
3kb from my zImage, but i'm not interested.
imel (writing from a
webmail)
----------------------------------------------------
This email was sent using http://webmail.cbn.net.id/
Hello [email protected],
Once you wrote about "Re: [PATCH] Single user linux":
> first, i think i owe you guys apology for didn't make myself
> clear, which is going harder if you irritated.
> even my subject went wrong, as the patch isn't really about
> single user (which confuse some people).
>
> for those who didn't read that patch, i #define capable(),
> suser(), and fsuser() to 1. the implication is all users
> will have root capabilities.
>
> then i tried to bring up the single user thing to hear
> opinions (not flames). and by that, i actually didn't mean
> to have users share the same uid/gid 0. i know somebody
> will need to differentiate user.
>
> so when everybody suggested playing with login, getty, etc.
> i know you have got the wrong idea. if i wanted to play
> on user space, i'd rather use capset() to set all users
> capability to "all cap". that's the perfect equivalent.
>
> so the user space solution (capset()) works, but then came
> the idea to optimize away. that's what blow everybody up.
> don't get me wrong, i always agree with rik farrow when he
> wrote in ;login: that we should build software with security
> in mind.
>
> but i also hate bloat. lets not go to arm devices, how about
> a notebook. it's a personal thing, naturally to people who
> doesn't know about computer, personal doesn't go with multi
> user. by that i mean user with different capabilities, not
> different persons.
>
> i haven't catch up with all my mails, but my response to
> some:
> - linux is stable not only because security.
> - linux was designed for multi-user, dos f.eks. is designed
> for personal use, so does epoc, palmos, mac, etc.
> - i even use plan9 with kfs restrictions disabled sometimes,
> cause i don't have cpu server, auth server, etc.
> - with that patch, people will still have authentication.
> so ssh for example, will still prevent illegal access, if
> you had an exploit you're screwed up anyway.
> sure httpd will give permission to everybody to browse
> a computer, but i don't think a notebook need to run it.
>
> so i guess i deserve opinions instead of flames. the
> approach is from personal use, not the usual server use.
> if you think a server setup is best for all use just say so,
> i'm listening.
Then, is there any advantage over booting linux with "single" option?
LILO: linux single
--
Best regards,
Leonid Mamtchenkov
System Administrator
On Wed, 25 Apr 2001 [email protected] wrote:
[snip]
> so i guess i deserve opinions instead of flames. the
> approach is from personal use, not the usual server use.
> if you think a server setup is best for all use just say so,
> i'm listening.
>
Heres one.. most of the time I spend cleaning up windows machines is not
because of software problems. Usually it's the user acidentally erasing
something or installing some program that just modified the boot files by
accident.
Protection makes the system easier not harder. You can add SUID
aplications to preform administrative tasks such as upgrading / config and
be sure that the user won't accidentally erase the system.
I've had users absolutely paranoid of breaking something on my systems
it's very reasuring for me to be able to point at the power switch and say
"see that? don't touch it and the sustem will be fine"
Gerhard
--
Gerhard Mack
[email protected]
<>< As a computer I find your faith in technology amusing.
[email protected] wrote:
> for those who didn't read that patch, i #define capable(),
> suser(), and fsuser() to 1. the implication is all users
> will have root capabilities.
And this is better than just having the system auto-login as root because......?
>
> then i tried to bring up the single user thing to hear
> opinions (not flames). and by that, i actually didn't mean
> to have users share the same uid/gid 0. i know somebody
> will need to differentiate user.
>
> so when everybody suggested playing with login, getty, etc.
> i know you have got the wrong idea. if i wanted to play
> on user space, i'd rather use capset() to set all users
> capability to "all cap". that's the perfect equivalent.
>
> so the user space solution (capset()) works, but then came
> the idea to optimize away. that's what blow everybody up.
> don't get me wrong, i always agree with rik farrow when he
> wrote in ;login: that we should build software with security
> in mind.
>
> but i also hate bloat. lets not go to arm devices, how about
> a notebook. it's a personal thing, naturally to people who
> doesn't know about computer, personal doesn't go with multi
> user. by that i mean user with different capabilities, not
> different persons.
>
So don't install any services. The security in the kernel is not even
bloat compared to some of the cruft that you can just not install.
> - with that patch, people will still have authentication.
> so ssh for example, will still prevent illegal access, if
> you had an exploit you're screwed up anyway.
> sure httpd will give permission to everybody to browse
> a computer, but i don't think a notebook need to run it.
See above.
>
> so i guess i deserve opinions instead of flames. the
> approach is from personal use, not the usual server use.
> if you think a server setup is best for all use just say so,
> i'm listening.
I have Linux on my PowerBook. I don't have sendmail, httpd, mysql, and a
billion other 'server' processes running. Does that still make it a server?
We're not flaming (well some of us anyways). Just pointing out (loudly)
where your thinking is flawed.
> nah, performance was never my consideration. i do save about
> 3kb from my zImage, but i'm not interested.
But you just said you hate bloat. What other reason do you have for
hating bloat?
--
=====================================================================
Mohammad A. Haque http://www.haque.net/
[email protected]
"Alcohol and calculus don't mix. Project Lead
Don't drink and derive." --Unknown http://wm.themes.org/
[email protected]
=====================================================================
On Wed, 25 Apr 2001, Ronald Bultje did have cause to say:
> Who says it needs to compile? Who says it needs software installed? Who
> says it needs to run the software itself?
My current project (and I'm just waiting for nfs and wvlan_cs to stabalize
on ARM before putting the final touches on it) is an ipaq nfsrooted to a
Debian image, over the wireless lan. Works like a champ, and it -does-
compile stuff reasonably fast (well, reasonably fast considering the data
is all on the far side of 11M/sec wireless.) My kit is mostly portable as
well, since the nfs server is on the libretto and runs just fine in my
backpack ;)
The next step is bludgeoning debian-arm into not running 50-100 little
servers I don't need on my PIM. But that may be the function of a
task-nfs-ipaq package or some such.
So far -multiuser- linux on PIMs ("true" linux, with X, etc, as distinct
from pocketlinux/qpe/etc, which are a different animal in this case) is
almost there. Web browsers are coming along nicely (and remote-X netscape
is usable, although barely) and there are several nice imap clients. (and
input methods ranging from a handwriting system to a little onscreen
keyboard, if you are in a situation where an external keyboard is not
feasable.)
---
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1 [http://www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a-->? C++++$ ULBS*++++$ P- L+++>+++++
E--- W+++ N+@ o+>$ K? w--->+++++ O- M V-- PS+() PE Y+@ PGP++() t
5--- X-- R tv+@ b++++>$ DI++++ D++(+++) G++ e* h(-)* r++ y++
------END GEEK CODE BLOCK------
So, are you saying, right now in front of the whole community, that you only
use Linux because you can develop on it? That if it wasn't for GCC you would
be playing Minesweeper right now?
I know thats not what you are saying, but thats how you come across. We
always tell everybody who would listen that Linux can hold its own as an
operating system. Not just because the code is open, and not just for the
development environment. Linux can hold its own because it is *good*. Not
perfect (there is no perfect operating system), but when you put it against
its peers, it rises to the top (<bigotry>along with its other unix
cousins</bigotry>).
So why wouldn't linux be ideal for an embedded situation. Why wouldn't an
open MP3 player be a better option that Media Player? We can't we use the
security, stability and power of Linux for a a suite of PIMs and Doom?I
Be proud of your operating system - you have 32 bits of multitasking power
and stability, and you can fit it into 512K. Lets see Redmond try that!
Jordan
On Tuesday 24 April 2001 18:32, Daniel Stone mentioned:
> On Tue, Apr 24, 2001 at 05:20:27PM -0700, Aaron Lehmann wrote:
> > On Wed, Apr 25, 2001 at 10:07:48AM +1000, Daniel Stone wrote:
> > > What real value does it have, apart from the geek "look at me, I'm
> > > using bash" value?
> >
> > I don't really want to get into it at the moment, but imagine hacking
> > netfilter without lugging a laptop around. PDA's are sleek and cool,
> > and using UNIX on them lets you write shell scripts to sort your
> > addresses and stuff like that. Basically it's everything that's cool
> > about Unix as a workstation OS scaled down to PDA-size.
>
> True, but then imagine trying to hack C (no, that's a CURLY BRACE, and a
> tab! not space! you just broke my makefiles! aargh!), and compiling
> Netfilter (it takes HOW MANY hours to compile init/main.c?!?) on a PDA.
> Hrmz.
At 8:45 AM +0100 2001-04-25, Alan Cox wrote:
> > True, but then imagine trying to hack C (no, that's a CURLY BRACE, and a
>> tab! not space! you just broke my makefiles! aargh!), and compiling
>> Netfilter (it takes HOW MANY hours to compile init/main.c?!?) on a PDA.
>
>Usual misguided assumptions
>
>1. Many PDA's have a keyboard
>2. The ipaq has an optional fold up keyboard
>3. Modern PDA's have 200Mhz processors and XScale will see some of them
> hitting 600MHz+
4. Linux is only ever used for developing Linux kernels. Or, under extreme circumstances, Linux apps.
--
/Jonathan Lundell.
hi imel,
On Tue, 24 Apr 2001 [email protected] wrote:
> problem is you guys are to unix-centric, try to be user-centric a little.
with all respect: the problem is that you do not listen.
as people keep trying to point out to you:
- you can have your single-user centric user environment (no logon)
while
- retaining advantages of multi-user security
no kernel changes needed.
ie: you can have your phone's user environment come straight up
(without needing a login or anything) and have security so that the
phone user can't do harmful things like delete system files.
you can have the best of all worlds...
> imel
--paulj
[email protected] wrote:
> for those who didn't read that patch, i #define capable(),
> suser(), and fsuser() to 1. the implication is all users
> will have root capabilities.
How is that not single user?
I have been doing single-user oriented Linux/GNU/unix longer than anyone
I'm aware of with exactly that focus. The one trivial patch I do to the
kernel disgusts the core Linux developers for reasons unrelated to single
user. cLIeNUX boots with 12 vt's logging in already as root. No kernel
molestation. (But stay tuned ;o) Rather than me contributing further to
the topic-skew, please have a browse at
http://www.clienux.com
Rick Hohensee
cLIeNUX user 0
On Wed, 25 Apr 2001, Rick Hohensee wrote:
> [email protected] wrote:
> > for those who didn't read that patch, i #define capable(),
> > suser(), and fsuser() to 1. the implication is all users
> > will have root capabilities.
>
> How is that not single user?
Every user still has it's own account, means profile etc.
Gru?,
Markus
--
| Gluecklich ist, wer vergisst, was nicht aus ihm geworden ist.
+---------------------------------------. ,---------------->
http://www.uni-ulm.de/~s_mschab/ \ /
mailto:[email protected] \_/
--------- Received message begins Here ---------
>
> On Wed, 25 Apr 2001, Rick Hohensee wrote:
>
> > [email protected] wrote:
> > > for those who didn't read that patch, i #define capable(),
> > > suser(), and fsuser() to 1. the implication is all users
> > > will have root capabilities.
> >
> > How is that not single user?
>
> Every user still has it's own account, means profile etc.
Until some user removes all the other users....
Or reads the other users mail....
Or changes the other users configuration....
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [email protected]
Any opinions expressed are solely my own.
On Wed, 25 Apr 2001 [email protected] wrote:
> so i guess i deserve opinions instead of flames. the
> approach is from personal use, not the usual server use.
> if you think a server setup is best for all use just say so,
> i'm listening.
Several distributions (Red Hat and Mandrake certainly) offer auto-login
tools. In conjunction with those tools, take the approach that Apple
used with OS X and setup "sudo" for administrative tasks on the machine.
This allows the end user to generally administer the machine without all
the need to hack the kernel, modify login, operate as root, etc. You can
even restrict their actions with it and log what they do.
In the end though, I really don't see the big deal with having a root
user for general home use. Even traditionally stand-alone operating
systems have gone to this model (Mac OS X) or are heading that way fast
(Windows XP). There are always ways to configure permissions, and even
in a stand-alone environment it's always better to protect against
accidental deletion of system critical files. In other words, the
benefits vastly outweigh the minor inconvenience.
John
[email protected] wrote:
> so when everybody suggested playing with login, getty, etc.
> i know you have got the wrong idea. if i wanted to play
> on user space, i'd rather use capset() to set all users
> capability to "all cap". that's the perfect equivalent.
>
The linux kernel ought to be flexible, so most people can use
it as-is. It can be used as-is for your purpose, and
it have been shown that this offer more security _without_
inconvenience. Your patch however removes multi-user security
for the many who needs it - that's why it never will get accepted.
Feel free to run your own patched kernels - but your
patch will never make it here.
> so the user space solution (capset()) works, but then came
> the idea to optimize away. that's what blow everybody up.
> don't get me wrong, i always agree with rik farrow when he
> wrote in ;login: that we should build software with security
> in mind.
>
If you really want optimization, remove all security instead of
merely killing a few basic tests.
> but i also hate bloat. lets not go to arm devices, how about
> a notebook. it's a personal thing, naturally to people who
> doesn't know about computer, personal doesn't go with multi
> user. by that i mean user with different capabilities, not
> different persons.
The notebook user might not care or understand about
multi-user security, but it is still useful. The user
have several daemons running that he don't know about,
they were installed by the distribution.
The security system can protect files from buggy
or cracked daemons.
And protecting the
configuration (and essential stuff like the user's GUI) from
being deleted by user accident is still a good thing.
The user who don't need password security can still have a "safe"
SUID admin program for necessary tasks like changing the
dialup phone number even though it resides in a protected
file. So you definitely want the protection system, even
in a "personal" appliance running linux. Because it
protects against stupid mistakes like experimenting
with editing files in the /etc directory on the notebook with
a word processor. Users don't understand why saving in
word processor format might be bad....
A notebook is a particularly bad example. Those with notebooks
might not want to use passwords all the time, but it is
very convenient if you have to leave a notebook with sensitive data
with someone you don't trust. Business secrets or something
as simple as a diary. This kind of users can be logged in
all the time, mostly avoiding passwords. And log out
in those few cases they need to leave the machine in
unsafe places.
>
> i haven't catch up with all my mails, but my response to
> some:
> - linux is stable not only because security.
Sure, but security definitely adds to its stability.
Instead of nuking it all, just remove what bothers you.
The security system has plenty to offer even when you
skip the password part.
> - linux was designed for multi-user, dos f.eks. is designed
> for personal use, so does epoc, palmos, mac, etc.
> - i even use plan9 with kfs restrictions disabled sometimes,
> cause i don't have cpu server, auth server, etc.
> - with that patch, people will still have authentication.
> so ssh for example, will still prevent illegal access, if
Nope. Someone ssh'ing into your system still
cannot guess someone elses password. They can log in
into their own account though, and abuse other
users accounts or the machine configuration because
there is no protection. Unprotected accounts only means
you get your own account _by default_, you have the
power to trash all the others. A malicious user could
even change the other users passwords and re-enable the
security system so they loose.
> you had an exploit you're screwed up anyway.
Many exploits are limited. Cracking a damenon running
as "nobody" or some daemon user may not be all that
satisfying - you might be unable to take over the machine.
An exploit doesn't necessarily give root access.
> so i guess i deserve opinions instead of flames. the
You get a lot of opinions. Don't mistake them for flames
just because they disagree with everything you say.
> approach is from personal use, not the usual server use.
> if you think a server setup is best for all use just say so,
> i'm listening.
Multi-user security is useful for much more than server use.
A good "personal" setup includes at least 3 users:
* root - for administration
* the user - for running the programs the user himself use.
I.e. the word processor on a notebook, the user inteface
on a linux phone, and so on.
* a nobody user, for safer daemons. If any kind of daemon
is used at all. Surprisingly many appliances might
run a daemon - a snmp daemon, or a webserver serving
the same purpose (So your can check your home
appliance from work perhaps)
Of course passwords can be skipped - maybe you don't worry
about guests messing up your phone settings. Still, a buggy
phone program shouldn't mess up other things. You don't want
the browser on those fancy web-enabled cellphones to
accidentally delete the address book due to some oddball
bug or exploit.
> i did say it clearly that i have other changes which i know
> won't be a clean patch (too many #ifdefs). f.eks. on my
> computer i didn't even compile user.c in, i don't have
> user_struct. filesystem and vfs code are affected by that
> patch already. memory access is important of course.
>
> > Then you can try to show a measurable performance
> difference.
>
> nah, performance was never my consideration. i do save about
> 3kb from my zImage, but i'm not interested.
You don't want the performance _or_ less memory used. Why then do
you want to optimize away the security system instead of merely
changing the userspace configuration a bit?
If you optimize away security then you probably want to
optimize away things like "login" as they are useless anyway
with such a kernel. Much simpler to remove only "login"
then.
Helge Hafting
On Thu, 26 Apr 2001, Helge Hafting wrote:
> The linux kernel ought to be flexible, so most people can use
> it as-is. It can be used as-is for your purpose, and
> it have been shown that this offer more security _without_
> inconvenience. Your patch however removes multi-user security
> for the many who needs it - that's why it never will get accepted.
> Feel free to run your own patched kernels - but your
> patch will never make it here.
i don't understand, that patch is configurable with 'n' as
default, marked "dangerous". so somebody who turned on that
option must be know what he's doing, doesn't understand english,
or has a broken monitor.
> If you really want optimization, remove all security instead of
> merely killing a few basic tests.
those tests responsible for almost all EACCESS & EPERM.
> The notebook user might not care or understand about
> multi-user security, but it is still useful. The user
> have several daemons running that he don't know about,
> they were installed by the distribution.
> The security system can protect files from buggy
> or cracked daemons.
must be a devil cursed distro, distributing "single-user"
kernel with live daemons. a division of redmon?
> And protecting the
> configuration (and essential stuff like the user's GUI) from
> being deleted by user accident is still a good thing.
>
> The user who don't need password security can still have a "safe"
> SUID admin program for necessary tasks like changing the
> dialup phone number even though it resides in a protected
> file. So you definitely want the protection system, even
> in a "personal" appliance running linux. Because it
> protects against stupid mistakes like experimenting
> with editing files in the /etc directory on the notebook with
> a word processor. Users don't understand why saving in
> word processor format might be bad....
hmm, the other thing i hate is policy. ever consider that
you're talking policy? maybe reboot() should sync() first?
> A notebook is a particularly bad example. Those with notebooks
> might not want to use passwords all the time, but it is
> very convenient if you have to leave a notebook with sensitive data
> with someone you don't trust. Business secrets or something
> as simple as a diary. This kind of users can be logged in
> all the time, mostly avoiding passwords. And log out
> in those few cases they need to leave the machine in
> unsafe places.
and that someone who had the notebook can't access sensitive
data without a passwd?
that's what i'm trying to say. if you carried your server,
and leave it in unsafe places, why would anybody try to crack
it? just get the harddisks put it in another computer, voila.
so much for security.
> > - linux is stable not only because security.
> Sure, but security definitely adds to its stability.
i don't know what you mean by stability. if you meant
linux can run a year without a reboot, what security
has anything to do with stability? the kernel is stable,
yes, do we here linux server got cracked yes, it's still
stable though.
> > - with that patch, people will still have authentication.
> > so ssh for example, will still prevent illegal access, if
> Nope. Someone ssh'ing into your system still
> cannot guess someone elses password. They can log in
> into their own account though, and abuse other
> users accounts or the machine configuration because
> there is no protection. Unprotected accounts only means
> you get your own account _by default_, you have the
> power to trash all the others. A malicious user could
> even change the other users passwords and re-enable the
> security system so they loose.
i didn't disable password! if someone got into a personal
machine through ssh by guessing, most likely that account
is the owner's. who else?
>
> > you had an exploit you're screwed up anyway.
> Many exploits are limited. Cracking a damenon running
> as "nobody" or some daemon user may not be all that
> satisfying - you might be unable to take over the machine.
> An exploit doesn't necessarily give root access.
that line was still about ssh. besides, if someone would
run a server for the world, then he must had drain bamage.
> You get a lot of opinions. Don't mistake them for flames
> just because they disagree with everything you say.
you haven't seen my inbox.
> Multi-user security is useful for much more than server use.
> A good "personal" setup includes at least 3 users:
> * root - for administration
> * the user - for running the programs the user himself use.
> I.e. the word processor on a notebook, the user inteface
> on a linux phone, and so on.
> * a nobody user, for safer daemons. If any kind of daemon
> is used at all. Surprisingly many appliances might
> run a daemon - a snmp daemon, or a webserver serving
> the same purpose (So your can check your home
> appliance from work perhaps)
but think about the idea of multi-user. it means protection
for the system and other users. that's a typical server needs.
and how about notebook? i can see that it need authentication
to use the system. does the user need to be protected from
other users? there's nobody else. well, maybe, like we all
used to, that user needed to protect him from himself.
so, system authentication is needed for both single-user and
multi-user. (let alone physical access)
user account authentication is certainly not needed for single-
user case.
> Of course passwords can be skipped - maybe you don't worry
> about guests messing up your phone settings. Still, a buggy
> phone program shouldn't mess up other things. You don't want
> the browser on those fancy web-enabled cellphones to
> accidentally delete the address book due to some oddball
> bug or exploit.
and you're hoping program with root suid will run perfectly?
> You don't want the performance _or_ less memory used. Why then do
> you want to optimize away the security system instead of merely
> changing the userspace configuration a bit?
>
> If you optimize away security then you probably want to
> optimize away things like "login" as they are useless anyway
> with such a kernel. Much simpler to remove only "login"
> then.
i wish it was only "a bit". what i want is to have all process
flags have PF_SUPERPRIV, but users still own their own uid.
doing it in userspace means i had to change this login, my
friend had to change that login, maybe this shell, that shell...
that's my setup. i still use login, so only those who i trust
can use my machine, yes my trusted user can do anything, but
hey it isn't a server. it's a workstation.
imel
On Wed, 25 Apr 2001, John Cavan wrote:
> Several distributions (Red Hat and Mandrake certainly) offer auto-login
> tools. In conjunction with those tools, take the approach that Apple
> used with OS X and setup "sudo" for administrative tasks on the machine.
> This allows the end user to generally administer the machine without all
> the need to hack the kernel, modify login, operate as root, etc. You can
> even restrict their actions with it and log what they do.
>
> In the end though, I really don't see the big deal with having a root
> user for general home use. Even traditionally stand-alone operating
>
you're right, we could do it in more than one way. like copying
with mcopy without mounting a fat disk. the question is where to put it.
why we do it is an important thing.
taking place as a clueless user, i think i should be able to do anything.
i'd be happy to accept proof that multi-user is a solution for
clueless user, not because it's proven on servers. but because it is
a solution by definition.
imel
On Thu, Apr 26, 2001 at 07:11:24PM +0700, [email protected] wrote:
>
> On Wed, 25 Apr 2001, John Cavan wrote:
>
> > Several distributions (Red Hat and Mandrake certainly) offer auto-login
> > tools. In conjunction with those tools, take the approach that Apple
> > used with OS X and setup "sudo" for administrative tasks on the machine.
> > This allows the end user to generally administer the machine without all
> > the need to hack the kernel, modify login, operate as root, etc. You can
> > even restrict their actions with it and log what they do.
> >
> > In the end though, I really don't see the big deal with having a root
> > user for general home use. Even traditionally stand-alone operating
> >
>
> you're right, we could do it in more than one way. like copying
> with mcopy without mounting a fat disk. the question is where to put it.
> why we do it is an important thing.
> taking place as a clueless user, i think i should be able to do anything.
> i'd be happy to accept proof that multi-user is a solution for
> clueless user, not because it's proven on servers. but because it is
> a solution by definition.
Look, all of this is VERY simple. There is only one single person you
have to convince to get this into the kernel. And you DO have to convince
him, because no matter how many others you try to force this upon, nothing
gets into the kernel without the consent of the almighty penguin.
So do us all a favour, send this patch to Linus. I'd give you a 1/10 chance
of getting a reply at all, and a 1/100000000000000 that the answer won't
be along the terms of "No way in hell, never!" (possibly worded a bit
different.) If you don't get any response in say a week or so, just give
up.
/David Weinehall
_ _
// David Weinehall <[email protected]> /> Northern lights wander \\
// Project MCA Linux hacker // Dance across the winter sky //
\> http://www.acc.umu.se/~tao/ </ Full colour fire </
[email protected] wrote:
> i'd be happy to accept proof that multi-user is a solution for
> clueless user, not because it's proven on servers. but because it is
> a solution by definition.
Clueless user deletes files critical to running the system. '!@#$% Why
can't I boot. Oh my gosh!! Linux sucks!'
--
=====================================================================
Mohammad A. Haque http://www.haque.net/
[email protected]
"Alcohol and calculus don't mix. Project Lead
Don't drink and derive." --Unknown http://wm.themes.org/
[email protected]
=====================================================================
> taking place as a clueless user, i think i should be able to do anything.
Yeah, I thought so when I started using Linux. I stopped thinking so,
when I accidentally blew up the FS on my datadrive and lost
nearly _everything_ I had written for 2 years...
> i'd be happy to accept proof that multi-user is a solution for
> clueless user, not because it's proven on servers. but because it is
> a solution by definition.
Let's turn the question the other way. It's you trying to convince
us, that everyone needs root access. What does a clueless user need root
access for?
Programming - no.
Writing documents - no.
Surfing the web - no.
Reading email - no.
Installing kernels - yes (but a clueless user won't do this).
Running viruses, that blow up the entire system - yes.
Installing software - yes. But how often do you do that? And is the 'su'
really so hard to remember?
If you really want to have different uids, why not hack xdm/login to
autologin. And when it autologins to a specific user, why do you want
different id's?
And if you really want everybody to have access to all files, you can
just do a 'chmod 777 /'. Perhaps set it up as a cronjob to run daily?
Besides you write, that a distro shipping single-user is evil. So you
want the clueless user to recompile his own kernel to enable single-user
mode (why do at all call it 'single-user' when you still have different
ID's?)... The clueless user probably does not even know what the kernel
is - and then have to recompile it...
Rasmus
--
-- [ Rasmus 'M?ffe' B?g Hansen ] --------------------------------------
if (getenv(EDITOR) == "vim") {karma++};
--------------------------------- [ moffe at amagerkollegiet dot dk ] -
David Weinehall wrote:
> So do us all a favour, send this patch to Linus. I'd give you a 1/10 chance
> of getting a reply at all, and a 1/100000000000000 that the answer won't
> be along the terms of "No way in hell, never!" (possibly worded a bit
> different.) If you don't get any response in say a week or so, just give
> up.
Amusing thing is that he did CC Linus on the patch and Linus hasn't said
a peep. I bet Linus laughed his ass off as he deleted the message
bit-by-bit.
--
=====================================================================
Mohammad A. Haque http://www.haque.net/
[email protected]
"Alcohol and calculus don't mix. Project Lead
Don't drink and derive." --Unknown http://wm.themes.org/
[email protected]
=====================================================================
On 2001.04.26 13:31:54 +0200 [email protected] wrote:
> On Thu, 26 Apr 2001, Helge Hafting wrote:
> > The linux kernel ought to be flexible, so most people can use
> > it as-is. It can be used as-is for your purpose, and
> > it have been shown that this offer more security _without_
> > inconvenience. Your patch however removes multi-user security
> > for the many who needs it - that's why it never will get accepted.
> > Feel free to run your own patched kernels - but your
> > patch will never make it here.
>
> i don't understand, that patch is configurable with 'n' as
> default, marked "dangerous". so somebody who turned on that
> option must be know what he's doing, doesn't understand english,
> or has a broken monitor.
I can make a virus, patch the kernel and send it in, with a 'N' by default.
But what is the use of this? Do you think this will be implemented???
Your thing is as dangerous as a virus, basically. It gives root to
everyone, although they have separate UIDs. And whenever there is a way out
(i.e. surfing the web, reading mail), there is a way in. So that would make
your system a very nice target to hack -> since you basically are root this
means they can change anything as soon as they have access. If you're not
root, they can't, since they can only do what you as a user can do.
The whole goal of your patch is to make computer life easier. This patch
doesn't do that - it goes far worse. We gave you a few suggestions on
better/easier ways to accomplish this goal - take them as advice and use
them instead.
Easy: chmod -R 777 / (same risk, though)
Good: use su for installing software (su -c "make install")
Can't get much easier than that (and if a clueless user needs to do this,
let him use redhat's RPM manager, "enter your password" with a nice
X-window, and press that button "install" - same effect)...
You don't need to patch the kernel for this...
--
Ronald Bultje
On Thu, 26 Apr 2001, [iso-8859-1] Rasmus B?g Hansen wrote:
> > i'd be happy to accept proof that multi-user is a solution for
> > clueless user, not because it's proven on servers. but because it is
> > a solution by definition.
>
> Let's turn the question the other way. It's you trying to convince
> us, that everyone needs root access. What does a clueless user need root
> access for?
what work around what? right now it's the kernel who thinks that root
is special, and applications work around that because there's a
division of super-user and plain user. is that a must?
it's trivial to say that in multi-user system, one user shall not mess
with other user. in multi-process, a process shall not mess with other
process.
but when it comes to a computer which only has one user, why would
it stop a user. because the kernel thinks it isn't right? if he
felt like killing random process, which is owned by other than the
user, is it a wrong thing to do? he owns the computer, he may do
anything he wants.
and i'm not even trying to convince anyone. communicating is
closer.
>
> And if you really want everybody to have access to all files, you can
> just do a 'chmod 777 /'. Perhaps set it up as a cronjob to run daily?
>
> Besides you write, that a distro shipping single-user is evil. So you
> want the clueless user to recompile his own kernel to enable single-user
iff that distro starts up daemons.
> mode (why do at all call it 'single-user' when you still have different
i wrote somewhere that it was my mistake to call it single-user when i
mean all user has the same root cap, and reduce "user" (account) to
"profile".
imel
On Thursday, April 26, 2001, at 07:03 AM, <[email protected]> wrote:
> he owns the computer, he may do anything he wants.
This sentence really stood out for me, and implies a profound lack of
understanding of multi-user machines. No offense intended.
I've been a Unix admin for over ten years, and I like to think that I
know my way around pretty well. But I do not and will NEVER log in to a
machine as root to do work. I am the only user of my MacOS X laptop and
home Linux boxes, and I still have my own personal login on all of
them. What's at issue is not ownership or trust, but one of
accountability and safety.
Any OS worth its weight in silicon will make a distinction between
blessed and unblessed users. It can be phrased in different ways --
root vs. non-root, admin vs. non-admin. But no one should EVER log in
to a machine as root. Period. (1)
Multi-user/modern operating systems exist precisely to destroy the fatal
flaw that you are attempting to reintroduce. Users should have reduced
privileges during normal use, and conditional privilege on demand. Safe
from User Error and no less functional on GUI-based systems.
People keep saying this, but I'll say it again. This can easily be done
in user-space. This HAS been done. Many times. Well. It's possible
to put a user in privileged mode automatically, but I'm not convinced
that an extra prompt to go into privileged mode is a bad thing from a
usability standpoint.
So it doesn't need to be in the kernel. And why put it there if it
doesn't need to be? Even if it's off by default, it's bloat. And
dangerous, conceptually flawed bloat that can't be disabled with
'chkconfig' or 'rpm -e'. And how many people will use it? And should
the kernel group allow them to from an out-of-box kernel? As I
understand it, part of the responsibility of the maintainers is to
maintain a conceptually focused kernel. There's nothing preventing you
from distributing your patch, but inserting this into "the" kernel seems
unacceptable IMVHO.
I think we understand the "why" of your patch, but I think you need to
elucidate further on how the ends justify the means.
Sorry to kick a dead horse,
--
Ken.
[email protected]
(1) Except for gnarly testbed/admin machines, etc. etc.
At 09:03 PM 4/26/01 +0700, you wrote:
>right now it's the kernel who thinks that root
>is special, and applications work around that because there's a
>division of super-user and plain user. is that a must?
Short answer: Yes.
Long answer: The division is artificial, but is absolutely necessary for
administration of a Unix-type system. For example, when the process
currently running is not running as a "superuser" process, the process
cannot run resources down to absolute zero -- think disk allocation. This
means that the administrator (who may be the same person as the "user") has
a chance of being able to recover from a runaway process gracefully by
being able to go in and kill that process before the whole system lays down
and dies.
Ever watch what happens when Windows runs out of "swap space" because the
swap file can't get any space? Ever try to recover from it? Make damn
sure you have the non-upgrade CD around when you try this. Even more
important, make sure you have multiple back-ups when you try this.
The whole point of "user" and "superuser" is that when the user does
something stupid or careless or even malicious, the superuser can bail the
system out. You don't usually work in superuser mode, and programs that
don't need superuser access don't get it.
Humans make mistakes a number of orders of magnitude more often than
computers do. The barrier helps minimize the damage.
Satch
>
>
> On Thursday, April 26, 2001, at 07:03 AM, <[email protected]> wrote:
> > he owns the computer, he may do anything he wants.
<snip>
> Any OS worth its weight in silicon will make a distinction between
> blessed and unblessed users. It can be phrased in different ways --
> root vs. non-root, admin vs. non-admin. But no one should EVER log in
> to a machine as root. Period. (1)
Also, there is another reason.
If you'r logged in as root, then any exploitable bug in large programs,
be it netscape, realplayer, wine, vmware, ... means that the
cracker owns your machine.
If they are not, then the cracker has to go through another significant
hoop, in order to get access to the machine.
For optimal security, you can do things like running netscape and other
apps under unpriveledged users, where they only have access to their own
files.
(Note, netscape/.. are just used as examples, I'm not saying they are
more buggy than others, just large, and hard to get bug-free)
On Thu, 26 Apr 2001 [email protected] wrote:
> you're right, we could do it in more than one way. like copying
> with mcopy without mounting a fat disk. the question is where to put it.
> why we do it is an important thing.
> taking place as a clueless user, i think i should be able to do anything.
> i'd be happy to accept proof that multi-user is a solution for
> clueless user, not because it's proven on servers. but because it is
> a solution by definition.
>
I think you have it backwards here, given that Linux works one way and you
want it to work another. Basically, I would suggest that it is up to you
to prove that multi-user is NOT a solution for "clueless" user, especially
given that there have been a number of suggestions on how to do it without
changing the kernel or even changing software.
If you can't prove the case, I rather suspect that your patch won't make
it. Don't feel bad though, I've yet to get one through either. :o)
John
On Thu, 26 Apr 2001, Ian Stirling wrote:
> Also, there is another reason.
> If you'r logged in as root, then any exploitable bug in large programs,
> be it netscape, realplayer, wine, vmware, ... means that the
> cracker owns your machine.
> If they are not, then the cracker has to go through another significant
> hoop, in order to get access to the machine.
> For optimal security, you can do things like running netscape and other
> apps under unpriveledged users, where they only have access to their own
> files.
>
> (Note, netscape/.. are just used as examples, I'm not saying they are
> more buggy than others, just large, and hard to get bug-free)
>
Heh. You receive all your email on your root account?
--
=====================================================================
Mohammad A. Haque http://www.haque.net/
[email protected]
"Alcohol and calculus don't mix. Project Lead
Don't drink and derive." --Unknown http://wm.themes.org/
[email protected]
=====================================================================
On Thu, 26 Apr 2001 [email protected] wrote:
>
> On Thu, 26 Apr 2001, [iso-8859-1] Rasmus B?g Hansen wrote:
> > > i'd be happy to accept proof that multi-user is a solution for
> > > clueless user, not because it's proven on servers. but because it is
> > > a solution by definition.
> >
> > Let's turn the question the other way. It's you trying to convince
> > us, that everyone needs root access. What does a clueless user need root
> > access for?
>
> what work around what? right now it's the kernel who thinks that root
> is special, and applications work around that because there's a
> division of super-user and plain user. is that a must?
Basically yes. But if you do not want _any_ security - you can drop it.
I started using Linux (and unix in general) in '96 (thanks Linus). And
now - feelin like an experienced linux (unix) user I feel more like
ever, I do _not_ want to be root
You do not understand the unix security aspects. You do not want unix
security and do not want unix. Then stop using it. People from redmond
allow you to trash your system without any special effort.
Stop bugging us. Have you noticed you never got response from Linus? He
is probably still laughing (or feeling pissed off) - Stop trashing his
(good) work, I know he is not the only one (I thank every Linux
developer)... Did you ever realize, that the unix security model hasn't
changed radically for 30 years? Beacause what? It is (opposite your
patch) mostly good.
> it's trivial to say that in multi-user system, one user shall not mess
> with other user. in multi-process, a process shall not mess with other
> process.
Ok. If you want to fuck up other people's processes, do it. Kill init
and get strange panics. If you want to crash other people's work, do
it. But begone from _my_ box!!!! Go to a bar and get drunk (as you do
not seem to have anything better to use your time for),.
> but when it comes to a computer which only has one user, why would
> it stop a user. because the kernel thinks it isn't right? if he
> felt like killing random process, which is owned by other than the
> user, is it a wrong thing to do? he owns the computer, he may do
> anything he wants.
Yeah. If he wants to do that he logs in as root. 'killall -1'? 'dd
if=/dev/zero of=/dev/kcore'. Yeah, crash your computer if you want. But
the 'clueless user does not want to'!
> and i'm not even trying to convince anyone. communicating is
> closer.
Who are you not trying to convince? You propose a patch - you try to
convince us to drop the unix secuity model...
> > And if you really want everybody to have access to all files, you can
> > just do a 'chmod 777 /'. Perhaps set it up as a cronjob to run daily?
>
> > Besides you write, that a distro shipping single-user is evil. So you
> > want the clueless user to recompile his own kernel to enable single-user
>
> iff that distro starts up daemons.
Or the user starts up daemons. He has root privileges after all.
> > mode (why do at all call it 'single-user' when you still have different
>
> i wrote somewhere that it was my mistake to call it single-user when i
> mean all user has the same root cap, and reduce "user" (account) to
> "profile".
Ok. My mistake. You want to use 'user profiles' but not use the
advantages...
You don't have to. You can use Windows if you want to. You can just use
root. As long as you do not hack /sbin/login or xdm, you will still have
to type login/password - no win, no gain.
If it wasn't for the nips, being so good at bulding ships
the yards would still be open in the clyde
get out to a war and get shot!
Rasmus
--
-- [ Rasmus 'M?ffe' B?g Hansen ] --------------------------------------
I don't suffer from insanity, i enjoy every minute of it!
--------------------------------- [ moffe at amagerkollegiet dot dk ] -
>
> On Thu, 26 Apr 2001, Ian Stirling wrote:
>
> > Also, there is another reason.
> > If you'r logged in as root, then any exploitable bug in large programs,
> > be it netscape, realplayer, wine, vmware, ... means that the
> > cracker owns your machine.
<snip>
> Heh. You receive all your email on your root account?
Nope.
For historical reasons (I gave out this address before I started using
linux) and mail to root here does not actually go to root.
[email protected]. writes:
> i wrote somewhere that it was my mistake to call it single-user when i
> mean all user has the same root cap, and reduce "user" (account) to
> "profile".
Seen this way it makes a tad more sense:
1. you and your spouse share the computer
2. you have different shells, mail folders, etc.
3. both of you are too lazy to use su or sudo
It isn't really bright having UID 0 have properties that can't
sanely be granted to other UIDs. Sure, we have the capability
bits, but just try using them. On the "would be nice" list goes
the ability to grant capabilities to a user, and the Novell-like
ability to grant one user complete access to the files of
another user without mucking with the permission bits on disk.
[email protected] wrote:
> i don't understand, that patch is configurable with 'n' as
> default, marked "dangerous". so somebody who turned on that
> option must be know what he's doing, doesn't understand english,
> or has a broken monitor.
This is a very marginal thing that very few people will want or need.
(You may think it is nifty - but we disagree on that)
If everybody get their favourite patch in with a config option
then we get a huge amount of config options, and maintainig the kernel
will be much harder because there is thousands of ifdefs for
all sorts of rare stuff. There will be your 5 ifdefs, and
26000 other people's 5 ifdefs. Someone making a change will have
to check if it works, but will it work with all sorts of combinations
of config options? What if someone makes a change that works fine,
but makes the kernel uncompileable if your option is turned on?
This guy didn't check your config option because he never use it
himself...
The maintainability issue is why kernel patches usually aren't accepted
when the problem can be solved by changing the userspace
configuration instead. (In your case by sybstituting "bash" for "getty"
in /etc/inittab) This is the case even with very good things -
fsck is a userspace program even though it is necessary for any system
with
a writeable filesystem.
You have another problem with the way all the leading developers
dislike your idea - buteven trying to convince them is useless as
you _still_ run up against "this feature is _easily_ done in userspace"
> > If you really want optimization, remove all security instead of
> > merely killing a few basic tests.
>
> those tests responsible for almost all EACCESS & EPERM.
Sure, but now you have a lots of if(1) {something} else {other thing}
and a better optimization would be to get rid of the entire test.
There is a lot of errors that can't happen with your patch, so
you really ought to remove the error handling cases too if
optimization is what drives you.
>
> > The notebook user might not care or understand about
> > multi-user security, but it is still useful. The user
> > have several daemons running that he don't know about,
> > they were installed by the distribution.
> > The security system can protect files from buggy
> > or cracked daemons.
>
> must be a devil cursed distro, distributing "single-user"
> kernel with live daemons. a division of redmon?
Is there something you don't understand, or do you really
want to run one process at a time?
You were talking about how a notebook is a personal thing,
with only one user. Well, the notebook user do of course want to
do a bunch of nifty things like read email on the thing. Guess what,
you need an email daemon for that! And many users don't want to know
the details of setting up an email daemon, so the distribution
install one by default. This kind of users would be outraged if
the distribution didn't - "what - I have to install more stuff just to
get my mail! windows do that out of the box why is this so difficult..."
There are several other examples of things users _expect_ from
a notebook, which just happens to include a daemon process running
under a different user-id for safety reasons. (For example
the print spooler daemon. Users want to print, and unix is nice
in that you don't have to wait for the printer - you can go
on editing something else while the printer slowly does
its work thanks to the print spooler daemon. This one is
installed by default too.)
They only ever _log in_ as one user, so the login prompt
can safely be eliminated in order to avoid the password hassle.
But you still want the multi-user security.
Please try to understand that the kernels concept of a "user"
don't mean a "person"! There is only one "person" using his/her
very personal device - the unix concept of users is a file
security thing. You don't want an error in the mail
software to use up all the diskspace or overwrite your
word processing files. And you don't want a printer driver
problem to mess up your mail or your personal files.
All these little things is included in good distributions, and
they don't cause serious trouble because they are all
protected against each other. Your machine is multi-user
even if it is strictly single-person!
If all this is new to you, please read up on unix before
suggesting too much. _Uninformed_ patches easily becomes
a nuance, good patches is usually written by people who
know very well what they work on. Excellent knowledge
of C isn't enough.
>
> > And protecting the
> > configuration (and essential stuff like the user's GUI) from
> > being deleted by user accident is still a good thing.
> >
> > The user who don't need password security can still have a "safe"
> > SUID admin program for necessary tasks like changing the
> > dialup phone number even though it resides in a protected
> > file. So you definitely want the protection system, even
> > in a "personal" appliance running linux. Because it
> > protects against stupid mistakes like experimenting
> > with editing files in the /etc directory on the notebook with
> > a word processor. Users don't understand why saving in
> > word processor format might be bad....
>
> hmm, the other thing i hate is policy. ever consider that
> you're talking policy? maybe reboot() should sync() first?
Reboot does indeed sync on my machine. That isn't the problem
here. The problem I described is that a clueless user might
try to change a config file with his word processor and save
it in word-processor format. This renders the file useless
as the programs who depend on config files don't understand
word processor format. A "nice synced reboot" won't help here,
as the ruined file is then saved properly, but the
contents are wrong.
A good security system fixes this though - a user simply isn't
allowed to mess up the config files in arbitrary ways. The
user is protected against his own lack of knowledge
or common sense. Similiar, a car engine don't explode if you
press the accelerator too hard at low RPM's. (A racing
car might - but racers _know_ how to handle such cars)
Unix appliances and personal computers need similiar
protection and the security system is used for that.
So what if the user _need_ to change the configuration?
Experts do this by using the root password. Non-experts
do this by running a safe config program. The config program
is SUID (it is privileged and auto-switch to the root user)
and it contains all sorts of undo options and safety checks
so the user cannot screw things up badly.
> > A notebook is a particularly bad example. Those with notebooks
> > might not want to use passwords all the time, but it is
> > very convenient if you have to leave a notebook with sensitive data
> > with someone you don't trust. Business secrets or something
> > as simple as a diary. This kind of users can be logged in
> > all the time, mostly avoiding passwords. And log out
> > in those few cases they need to leave the machine in
> > unsafe places.
>
> and that someone who had the notebook can't access sensitive
> data without a passwd?
> that's what i'm trying to say. if you carried your server,
> and leave it in unsafe places, why would anybody try to crack
> it? just get the harddisks put it in another computer, voila.
> so much for security.
An encrypted filesystem prevents even this - a cracker _can't_
read that disk without the password. Because there
is no workaround even with a purpose-built "nasty" kernel.
This is usually overkill though. Normal users worry about
things like your sister taking a sneak look at your diary
(stored in a word processor file). Or in a business
setting: A visitor taking a look at your business documents
while you fetch the coffee for the meeting. He don't have time
for disassembling the computer, but he have time
for reading a few documents. A simple password
protect against this.
What I do here is providing a few (of many) examples
of why passwords sometimes is a good idea even on
personal machines.
> > > - linux is stable not only because security.
> > Sure, but security definitely adds to its stability.
>
> i don't know what you mean by stability. if you meant
> linux can run a year without a reboot, what security
> has anything to do with stability? the kernel is stable,
> yes, do we here linux server got cracked yes, it's still
> stable though.
>
> > > - with that patch, people will still have authentication.
> > > so ssh for example, will still prevent illegal access, if
> > Nope. Someone ssh'ing into your system still
> > cannot guess someone elses password. They can log in
> > into their own account though, and abuse other
> > users accounts or the machine configuration because
> > there is no protection. Unprotected accounts only means
> > you get your own account _by default_, you have the
> > power to trash all the others. A malicious user could
> > even change the other users passwords and re-enable the
> > security system so they loose.
>
> i didn't disable password! if someone got into a personal
> machine through ssh by guessing, most likely that account
> is the owner's. who else?
Yeah, but what if there are several accounts?
I have an account on my machine where strangers can log in in order
to play network games. There is a password, but it is handed out
to a bunch of strangers I have no particular reason to trust.
This is not a problem as my machine has multi-user security.
They cannot delete _my_ files, or even read them, even though
they can log into the machine. They cannot even run other
programs than the games, as they have no permission.
That wouldn't work with your patch. They would still only
be able to log into their own game account because of
the password security in ssh, but they definitely _would_
be able to delete _my_ personal account without
logging into it - because you disabled security. And they
could delete the email software so I don't get mail. And they
could delete the system software and the kernel, so the
machine goes down and remains down. Security prevents all that.
>
> >
> > > you had an exploit you're screwed up anyway.
> > Many exploits are limited. Cracking a damenon running
> > as "nobody" or some daemon user may not be all that
> > satisfying - you might be unable to take over the machine.
> > An exploit doesn't necessarily give root access.
>
> that line was still about ssh. besides, if someone would
> run a server for the world, then he must had drain bamage.
>
Not at all. There are many game servers out there where
people all over the world can log in and run games.
But security prevents them for doing anything _but_ running
games, so there is no problem. And there are anonymous
ftp server where anybode can log in...
> > You get a lot of opinions. Don't mistake them for flames
> > just because they disagree with everything you say.
>
> you haven't seen my inbox.
No, I just see the replies on the linux kernel list.
A few flames, and lots of people who merely disagree and try
to tell why they thing your patch and the idea behind
it is no good.
> > Multi-user security is useful for much more than server use.
> > A good "personal" setup includes at least 3 users:
> > * root - for administration
> > * the user - for running the programs the user himself use.
> > I.e. the word processor on a notebook, the user inteface
> > on a linux phone, and so on.
> > * a nobody user, for safer daemons. If any kind of daemon
> > is used at all. Surprisingly many appliances might
> > run a daemon - a snmp daemon, or a webserver serving
> > the same purpose (So your can check your home
> > appliance from work perhaps)
>
> but think about the idea of multi-user. it means protection
> for the system and other users. that's a typical server needs.
>
> and how about notebook? i can see that it need authentication
> to use the system. does the user need to be protected from
> other users? there's nobody else. well, maybe, like we all
> used to, that user needed to protect him from himself.
>
> so, system authentication is needed for both single-user and
> multi-user. (let alone physical access)
> user account authentication is certainly not needed for single-
> user case.
As I have said already in this mail - a single-user computer
need the security system to protect the _system software_ from
the (single) user, and to protect the _users_ files from
possible bugs in various system software like mail software,
printer drivers and various other things the user
might want to run. Some people thinks it is cool to
run a webserver on their office machine, even if it only servers
one page. Security makes things like that safer too.
You may or may not need authentication. But you definitely
want security.
A newbie experimenting might stumble upon the command that
deletes all files on the system. That won't kill a unix system,
the user will merely loose his own personal files, because
he has no permission for deleting system files.
Try this on a windows 98 box (which don't have security, exactly
the way you tried to patch the kernel) and everything goes,
or at least a lot of things until the system crashes due
to a missing system file. The system migh be unable
to delete everything, but it will certainly manage
to delete enough to amke the machine unuseable and in need
of a reinstall.
This protection system ensures that you typically never need to
reinstall linux due to user mistakes. (You may want to
upgrade often to get the latest software - but you don't
need to reinstall to get a upgrade.)
> > Of course passwords can be skipped - maybe you don't worry
> > about guests messing up your phone settings. Still, a buggy
> > phone program shouldn't mess up other things. You don't want
> > the browser on those fancy web-enabled cellphones to
> > accidentally delete the address book due to some oddball
> > bug or exploit.
>
> and you're hoping program with root suid will run perfectly?
>
> > You don't want the performance _or_ less memory used. Why then do
> > you want to optimize away the security system instead of merely
> > changing the userspace configuration a bit?
> >
> > If you optimize away security then you probably want to
> > optimize away things like "login" as they are useless anyway
> > with such a kernel. Much simpler to remove only "login"
> > then.
>
> i wish it was only "a bit". what i want is to have all process
> flags have PF_SUPERPRIV, but users still own their own uid.
> doing it in userspace means i had to change this login, my
> friend had to change that login, maybe this shell, that shell...
>
> that's my setup. i still use login, so only those who i trust
> can use my machine, yes my trusted user can do anything, but
> hey it isn't a server. it's a workstation.
I wonder what you want different UID's for then. Why not set all the
UID's to 0, you'll still have separate usernames, and separate
home directories so you can have different setups and so on.
I cannot really see what you use the UID's for?
But still, if you want everybody to be able to do anything _and_
have separate UIDS, try userspace options. Possible ways:
1. A single chmod command can make all files available.
Something like "chmod -R /* oug+rwx" You may have to
do that as root - you won't need root later.
2. Or run a similiar chmod on /bin, /sbin and /usr/bin
that makes all executables SUID. power to the users!
3. Or let everybody be members of group 0 and run
"chmod g+rwx /* -R"
There's a multitude of easy ways to achieve the behavior you
want without patching the kernel. That alone _ensures_
it won't get into the kernel. They way people dislike
your idea don't make it better, but it wouldn't help
even if you could convince them.
Many newbie ideas are met with "no, the idea is bad but
you can achieve what you want another way, like this:"
Smart people learn from such things. Some other
keep arguing when there is nothing to achieve.
If you're a unix newbie, please consider the option that
the other people may have a point. They know things you don't,
so asking "why" is a much better idea than insisting on
an unpopular idea. They don't all take the time
to explain why they don't like your patch, that don't mean
they don't have solid reasons.
Helge Hafting
On Thu, 26 Apr 2001, John Cavan wrote:
> I think you have it backwards here, given that Linux works one way and you
yeah, it was a patch for linux, but i wasn't thinking linux. there
are quite many os out there. and i don't think they're different
just because they have programmers with different intelligence level.
> If you can't prove the case, I rather suspect that your patch won't make
> it. Don't feel bad though, I've yet to get one through either. :o)
oh no, that patch was useful to explain the idea. i don't even think
it's the right way. but it's a good way to exercise the idea.
well, thanks anyway.
imel
On Wed, Apr 25, 2001 at 10:34:56AM +1000, Daniel Stone wrote:
> On Wed, Apr 25, 2001 at 01:16:03AM +0100, Alan Cox wrote:
> > > > Quit being a naysayer. UNIX on a PDA is a wet dream.
> > > What real value does it have, apart from the geek "look at me, I'm using
> > > bash" value?
> >
> > It means I can do anything on my ipaq I can do anywhere else. I can run
> > multiple apps at a time. I can run X11. I can run the palm emulator even ;)
>
> How long does it take you to write "date"? Plus, aren't you content with
> IRCing on your *phone*? ;)
>
> > Its the same reason Linux is valuable on an S/390 mainframe. Its a common pool
> > of apps, environments and tools. Anything your PC can do, my ipaq can do.
>
> OK. "time make bzImage". Of course, mine's really slow (and I will consider
> myself publically humiliated if my only Linux machine is beaten on a kernel
Okay. Does the word *choice* ring a bell ? Agenda VR3s are supplied with Linux
kernel (modified), and it gives you the freedom to choose what kind of SW
you want to use -- hey, it's linux and when the app fits in the memory,
there's no stopping you. Different look and feel? Different graffitti? Different
kernel? You name it and you got it (well mostly) ;-)
--
Kind regards,
Robert Varga
------------------------------------------------------------------------------
[email protected] http://hq.sk/~nite/gpgkey.txt
On Fri, Apr 27, 2001 at 03:12:39PM +0200, Robert Varga wrote:
> On Wed, Apr 25, 2001 at 10:34:56AM +1000, Daniel Stone wrote:
> > On Wed, Apr 25, 2001 at 01:16:03AM +0100, Alan Cox wrote:
> > > > What real value does it have, apart from the geek "look at me, I'm using
> > > > bash" value?
> > >
> > > It means I can do anything on my ipaq I can do anywhere else. I can run
> > > multiple apps at a time. I can run X11. I can run the palm emulator even ;)
> >
> > How long does it take you to write "date"? Plus, aren't you content with
> > IRCing on your *phone*? ;)
>
> Okay. Does the word *choice* ring a bell ? Agenda VR3s are supplied with Linux
> kernel (modified), and it gives you the freedom to choose what kind of SW
> you want to use -- hey, it's linux and when the app fits in the memory,
> there's no stopping you. Different look and feel? Different graffitti? Different
> kernel? You name it and you got it (well mostly) ;-)
I know all this, see my very first point above. I just can't see the real
practical value. I'd more than likely find a Palm more productive, as it's
simple, does one task, and does it well. If I wanted to buy a PDA, I'd get a
Palm. If I wanted to buy a miniature laptop, I'd get a PictureBook or
somesuch. I just can't see the practical use.
--
Daniel Stone
[email protected]
On Fri, 27 Apr 2001, Robert Varga wrote:
> On Wed, Apr 25, 2001 at 10:34:56AM +1000, Daniel Stone wrote:
> > On Wed, Apr 25, 2001 at 01:16:03AM +0100, Alan Cox wrote:
> > > > > Quit being a naysayer. UNIX on a PDA is a wet dream.
> > > > What real value does it have, apart from the geek "look at me, I'm using
> > > > bash" value?
Hmm...How about free and open source, uniform app base, easy access by
third party vendors.
Also it seems to me last I checked PDA's were at least equvalent to the
386 which is ostensibly the bottom linux rung.
As for the objection about slow compile times, get real. No PDA is going
to compile anything. All compilations happen on your desktop with a
crosscompiler. PDA's are for running handy little apps, not development
work.
Or are we saying M$ CE is as good as it gets. :P
Jay
Helge Hafting wrote:
> You were talking about how a notebook is a personal thing,
> with only one user. Well, the notebook user do of course want to
> do a bunch of nifty things like read email on the thing. Guess what,
> you need an email daemon for that! And many users don't want to know
> the details of setting up an email daemon, so the distribution
> install one by default. This kind of users would be outraged if
> the distribution didn't - "what - I have to install more stuff just to
> get my mail! windows do that out of the box why is this so difficult..."
You don't need to be running an e-mail daemon just to read e-mail.
--
=====================================================================
Mohammad A. Haque http://www.haque.net/
[email protected]
"Alcohol and calculus don't mix. Project Lead
Don't drink and derive." --Unknown http://wm.themes.org/
[email protected]
=====================================================================
Hi!
> > > Since when, did mobile phones == computers?
> >
> > read the news! i'm programming nokia 9210 with c++, is that
> > computer enough?
>
> Aah. I see. Where was this? I never saw it.
9210 has qwerty keyboard.
> > i bet if you programmed one, you'd wish you have posix
> > interface.
>
> That may be so, so hack up your own OS. It's a MOBILE PHONE, it needs to be
> absolutely *rock solid*. Look at the 5110, that's just about perfect. The
> 7110, on the other hand ...
And point is?
> > > > that also explain why win95 user doesn't want to use NT. not
> > > > because they can't afford it (belive me, here NT costs only
> > > > us$2), but additional headache isn't acceptable.
> > >
> > > So, let them stay in Win95. They don't *need* NT.
> >
> > and how's stability, speed, etc. they read. is there a linux
> > advocate around here?
>
> There are Linux advocates, but I'd say most of us are sane enough to use the
> right-tool-for-the-job approach. And UNIX on a phone is pure
> overkill.
Is it? Let's see.
You want your mobile phone to read mail. That's SMTP. Oh, and SMTP
needs to run over something. That's TCP/IP over PPP or SLIP. Oh and
you want web access. Add HTTP to the list.
[above is reasonable even for "normal" mobile phone; those below
require keyboard]
You'd like to ssh from your mobile phone. Add ssh. You'd like to ssh
*to* your mobile phone, because it keyboard sucks. That sshd. You'd
like to be able to let others to play games on your mobile phone, oh
that means multiuser mode.
You see? Linux has much stuff you'll need.
> > okay, it wouldn't cost me. but it surely easier if everybody used
> > linux, so i could put my ext2 disk everywhere i want.
> >
> > hey, it's obvious that it's not for a server!
> > i try to point out a problem for people not on this list, don't
> > work around that problem.
>
> Your sister won't notice much advantage. Linux on a workstation actually has
> *disadvantages* (unfamiliar interface, unintuitive same, etc), as opposed to
> 'Doze on a workstation. Sure it's more stable, and the tiniest bit faster,
> but what's that really matter to your sister, if she can't even figure out
> how to use it?
My brother is 10 and he uses suse7.2 installation just fine. He likes
it more than windoze 2000 (I deleted) because there are more games in
kde than in windows. [I'd prefer gnome.]
> -d, who owns a 7110 and can lock it solid, or get it to do funny resetting
> tricks, at least once every 2 days
Hmm, maybe your 7110 needs memory protection so that runaway calendar
can not hurt basic functions? ;-).
Pavel
--
I'm [email protected]. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [email protected]
On Thu, Apr 26, 2001 at 09:35:45PM +0200, Pavel Machek wrote:
> Hi!
Hola.
> > > read the news! i'm programming nokia 9210 with c++, is that
> > > computer enough?
> >
> > Aah. I see. Where was this? I never saw it.
>
> 9210 has qwerty keyboard.
He said "read the news". I've seen the 9110 and 9210's, I was asking where
this news was.
> > > i bet if you programmed one, you'd wish you have posix
> > > interface.
> >
> > That may be so, so hack up your own OS. It's a MOBILE PHONE, it needs to be
> > absolutely *rock solid*. Look at the 5110, that's just about perfect. The
> > 7110, on the other hand ...
>
> And point is?
The point is that you need a known good, absolutely rock-solid OS to do it,
and IMHO, you really need a customised job, not something like Linux, which
is a monolith in comparison.
> > > and how's stability, speed, etc. they read. is there a linux
> > > advocate around here?
> >
> > There are Linux advocates, but I'd say most of us are sane enough to use the
> > right-tool-for-the-job approach. And UNIX on a phone is pure
> > overkill.
>
> Is it? Let's see.
>
> You want your mobile phone to read mail. That's SMTP. Oh, and SMTP
> needs to run over something. That's TCP/IP over PPP or SLIP. Oh and
> you want web access. Add HTTP to the list.
In the mobile world, that is *all* WAP.
> [above is reasonable even for "normal" mobile phone; those below
> require keyboard]
>
> You'd like to ssh from your mobile phone. Add ssh. You'd like to ssh
> *to* your mobile phone, because it keyboard sucks. That sshd. You'd
> like to be able to let others to play games on your mobile phone, oh
> that means multiuser mode.
I'd *like* to, sure, but this is impractical because the mobile links suck
so hard. Dunno about you, but it takes a few seconds to pull in a <1k page.
Ugh. SSH? Games, sure, I point my phone at a 7110 or 6210 and I can play
2-player Snake 2 :)
> You see? Linux has much stuff you'll need.
True, but you have to be wary of overkill, like I said.
> > Your sister won't notice much advantage. Linux on a workstation actually has
> > *disadvantages* (unfamiliar interface, unintuitive same, etc), as opposed to
> > 'Doze on a workstation. Sure it's more stable, and the tiniest bit faster,
> > but what's that really matter to your sister, if she can't even figure out
> > how to use it?
>
> My brother is 10 and he uses suse7.2 installation just fine. He likes
> it more than windoze 2000 (I deleted) because there are more games in
> kde than in windows. [I'd prefer gnome.]
I've used RedHat since I was about 11, Debian since 13. It's not that hard,
if you can just get used to it. But you're playing with yourself if you
think that KDE has more games than Win2k ... Black & White? All the Star
Wars games? etc ... I know a lot of them are being ported to Linux, most via
Loki, but still ...
(I use GNOME, and the panel giving me Bus errors is starting to annoy me).
> > -d, who owns a 7110 and can lock it solid, or get it to do funny resetting
> > tricks, at least once every 2 days
>
> Hmm, maybe your 7110 needs memory protection so that runaway calendar
> can not hurt basic functions? ;-).
Oh, I think it's just to do with changing state, seeing as most of the
lockups I get are when I hit keys really, really quickly in sequence, and
one lands just as the screen's blank, and it's changing state (snake 2 can
also kill it).
--
Daniel Stone
[email protected]
Hi!
> > > What real value does it have, apart from the geek "look at me, I'm using
> > > bash" value?
> >
> > I don't really want to get into it at the moment, but imagine hacking
> > netfilter without lugging a laptop around. PDA's are sleek and cool,
> > and using UNIX on them lets you write shell scripts to sort your
> > addresses and stuff like that. Basically it's everything that's cool
> > about Unix as a workstation OS scaled down to PDA-size.
>
> True, but then imagine trying to hack C (no, that's a CURLY BRACE, and a
> tab! not space! you just broke my makefiles! aargh!), and compiling
So you telnet to your PDA from some real machine. And you don't need
to write C code in order for unix environment to be usable. 50% of
unix users I know use it for pine/mutt emacs/vi talk/irc/mud kind of
stuff.
> Netfilter (it takes HOW MANY hours to compile init/main.c?!?) on a PDA.
> Hrmz.
How many hours? I'd say less than minute. In todays PDAs, 80MHz mips
cpu is *slow*.
Pavel
--
I'm [email protected]. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [email protected]
Hi!
> >>> And UNIX on a phone is pure overkill.
> >>
> >>Quit being a naysayer. UNIX on a PDA is a wet dream.
> >
> >http://www.agendacomputing.com/ (not that the reviews have been very kind)
>
> Nor has an official product been released. Reviewing hardware
> and software in open development model before it is officially
> stamped "final release" is unfair to say the least. I follow the
> agenda list and it is a nice piece of hardware and the software
Is there agenda emulator, somewhere? Is there their root filesystem
available for download? [Besides, anyone knows of vtech helio emulator
for linux? Only version I saw was windows...]
I'm running linux on philips velo, which is similar to agenda, and I
guess I could use some of their stuff.
(Anybody knows about support of audio on r39xx companion chip? Or
about voltmeters support?)
Pavel
--
I'm [email protected]. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [email protected]
Hi!
> > OK. "time make bzImage". Of course, mine's really slow (and I will consider
> > myself publically humiliated if my only Linux machine is beaten on a kernel
> > compile by an iPAQ). I 'spose, if it only goes into suspend, the ability to
> > write "uptime" on it constitutes a walking penis extension after a while?
>
> When I first started I compiled my linux kernels on a 386 dx with 8 mb ram
> heh. I think a lot of the current PDAs are faster.
My pocket computer is 40MHz mips r3902, likely faster than your
386dx. That's 3 years old. Anything you can buy today is at least
twice as fast. [hell, I saw 8MB ram 2MB flash 80MHz mips machine in
size of palm for $100 (vtech helio) -- I'll tell you where to buy it
when you ask.]
Pavel
--
I'm [email protected]. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [email protected]
Pavel Machek <[email protected]> sez:
> available for download? [Besides, anyone knows of vtech helio emulator
> for linux? Only version I saw was windows...]
http://www.kernelconcepts.de/helio/helio-emulator-1.0.6b.tar.gz
Works slowly, but okay. Your X server must be set to 15 or 16bpp.
On Thu, Apr 26, 2001 at 09:41:13PM +0200, Pavel Machek wrote:
> > When I first started I compiled my linux kernels on a 386 dx with 8 mb ram
> > heh. I think a lot of the current PDAs are faster.
>
> My pocket computer is 40MHz mips r3902, likely faster than your
> 386dx. That's 3 years old. Anything you can buy today is at least
> twice as fast. [hell, I saw 8MB ram 2MB flash 80MHz mips machine in
> size of palm for $100 (vtech helio) -- I'll tell you where to buy it
> when you ask.]
The Compaq iPaq uses an Intel StrongARM SA1110 CPU running at 190MHz.
Integer performance for a 221MHz SA1110 is comparable with a Pentium
180 (on the average), so I guess that the iPaq performance is
compatable with a P166.
Erik
--
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands
Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [email protected]
WWW: http://www-ict.its.tudelft.nl/~erik/
On Fri, Apr 27, 2001 at 07:42:25AM -0500, Collectively Unconscious wrote:
> Also it seems to me last I checked PDA's were at least equvalent to the
> 386 which is ostensibly the bottom linux rung.
Check out the Compaq iPaq 3600 series.
> As for the objection about slow compile times, get real. No PDA is going
> to compile anything. All compilations happen on your desktop with a
> crosscompiler. PDA's are for running handy little apps, not development
> work.
Ehm, I know that people actually use their iPaq to compile things
natively. Plug in an IBM microdrive, add a foldable keyboard and you
get a complete Unix workstation in pocket format. For more information,
see http://www.handhelds.org/ .
Erik
[who also natively compiles kernels on a platform comparable to the
iPaq -- see http://www.lart.tudelft.nl/ ]
--
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands
Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [email protected]
WWW: http://www-ict.its.tudelft.nl/~erik/
Not to mention fold up keyboard, IBM microdrive, etc. So you
can run the ARM Debian distro either via NFS (with the problems that
entails), or even locally on a microdrive (or I suppose you could
also play with an IDE or SCSI controller if you were really insane).
On the kernel software side, we also have IPV6/mobile IP running. We're
using Dave Woodhouse's JFFS2 with compression for our file system (Compressed
journalling flash file system) on flash.
In terms of apps, various PIM stuff, though needs lots of work,
other goodies like GPS applications, etc. Mozilla in previous versions
has been known to work. Tons of games, doom, etc.
MP3 players (at least 3). Gnome core libraries.
Python, Java 2 standard edition, swing, all running etc.....
Lots of work/fun left to do, of course, in all areas.
Shall we just say we're having lots and lots and lots of fun :-).
These are real computers.
Lots of dust in the air: lots should have settled by June. In particular,
look at the Familiar work.
See http://www.handhelds.org. I apologize about the state of our web site:
I've done much of the maintenance in the past, but I've been out for some
surgery and life has been insane ever since. Most of the interesting
stuff is in the Wiki. And iPAQ's are not as unobtanium as they once were:
we're in really high volume production (>100K/month) but demand still
outstrips supply (sigh...).
Come join the party...
- Jim Gettys
> Sender: [email protected]
> From: Disconnect <[email protected]>
> Date: Wed, 25 Apr 2001 10:17:55 -0400
> To: Ronald Bultje <[email protected]>
> Cc: [email protected]
> Subject: Re: [PATCH] Single user linux
> -----
> On Wed, 25 Apr 2001, Ronald Bultje did have cause to say:
>
> > Who says it needs to compile? Who says it needs software installed? Who
> > says it needs to run the software itself?
>
> My current project (and I'm just waiting for nfs and wvlan_cs to stabalize
> on ARM before putting the final touches on it) is an ipaq nfsrooted to a
> Debian image, over the wireless lan. Works like a champ, and it -does-
> compile stuff reasonably fast (well, reasonably fast considering the data
> is all on the far side of 11M/sec wireless.) My kit is mostly portable as
> well, since the nfs server is on the libretto and runs just fine in my
> backpack ;)
>
> The next step is bludgeoning debian-arm into not running 50-100 little
> servers I don't need on my PIM. But that may be the function of a
> task-nfs-ipaq package or some such.
>
> So far -multiuser- linux on PIMs ("true" linux, with X, etc, as distinct
> from pocketlinux/qpe/etc, which are a different animal in this case) is
> almost there. Web browsers are coming along nicely (and remote-X netscape
> is usable, although barely) and there are several nice imap clients. (and
> input methods ranging from a handwriting system to a little onscreen
> keyboard, if you are in a situation where an external keyboard is not
> feasable.)
>
> ---
--
Jim Gettys
Technology and Corporate Development
Compaq Computer Corporation
[email protected]