Re: what's next for the linux kernel?

Re: what's next for the linux kernel?

[Robert Hancock]

Luke Kenneth Casson Leighton wrote:
> and, what is the linux kernel?
> 
> it's a daft, monolithic design that is suitable and faster on
> single-processor systems, and that design is going to look _really_
> outdated, really soon.

Well, it sounds like it works pretty well on such things as 512 CPU 
Altix systems, so it sounds like the suggestion that Linux is designed 
solely for single-processor systems and isn't suitable for multicore, 
hyperthreaded CPUs doesn't hold much water..

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

Re: what's next for the linux kernel?

[Gene Heskett]

On Sunday 02 October 2005 18:43, Robert Hancock wrote:
>Luke Kenneth Casson Leighton wrote:
>> and, what is the linux kernel?
>>
>> it's a daft, monolithic design that is suitable and faster on
>> single-processor systems, and that design is going to look _really_
>> outdated, really soon.
>
>Well, it sounds like it works pretty well on such things as 512 CPU
>Altix systems, so it sounds like the suggestion that Linux is designed
>solely for single-processor systems and isn't suitable for multicore,
>hyperthreaded CPUs doesn't hold much water..

Ahh, yes and no, Robert.  The un-answered question, for that
512 processor Altix system, would be "but does it run things 512
times faster?"  Methinks not, by a very wide margin.  Yes, do a lot
of unrelated things fast maybe, but render a 30 megabyte page with
ghostscript in 10 milliseconds?  Never happen IMO.

And Christoph in the next msg, calls him 1/2 drunk.  He doesn't come
across to me as being more than 1 beer drunk.  And he does make some
interesting points, so if they aren't valid, lets use proveable logic
to shoot them down, not name calling and pointless rhetoric.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.35% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Re: what's next for the linux kernel?

[Vadim Lobanov]

On Sun, 2 Oct 2005, Gene Heskett wrote:

> On Sunday 02 October 2005 18:43, Robert Hancock wrote:
> >Luke Kenneth Casson Leighton wrote:
> >> and, what is the linux kernel?
> >>
> >> it's a daft, monolithic design that is suitable and faster on
> >> single-processor systems, and that design is going to look _really_
> >> outdated, really soon.
> >
> >Well, it sounds like it works pretty well on such things as 512 CPU
> >Altix systems, so it sounds like the suggestion that Linux is designed
> >solely for single-processor systems and isn't suitable for multicore,
> >hyperthreaded CPUs doesn't hold much water..
>
> Ahh, yes and no, Robert.  The un-answered question, for that
> 512 processor Altix system, would be "but does it run things 512
> times faster?"  Methinks not, by a very wide margin.  Yes, do a lot
> of unrelated things fast maybe, but render a 30 megabyte page with
> ghostscript in 10 milliseconds?  Never happen IMO.

This is only true for workloads that are parallelizable. I don't think
any kernel is quite good enough to divine what a single-threaded
userland application is doing and make its work parallel.

That is to say, if we are going to look at examples (and so we should),
then we need to pick an example that is actually expected to benefit
from many-processor machines.

> And Christoph in the next msg, calls him 1/2 drunk.  He doesn't come
> across to me as being more than 1 beer drunk.  And he does make some
> interesting points, so if they aren't valid, lets use proveable logic
> to shoot them down, not name calling and pointless rhetoric.
>
> --
> Cheers, Gene
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> 99.35% setiathome rank, not too shabby for a WV hillbilly
> Yahoo.com and AOL/TW attorneys please note, additions to the above
> message by Gene Heskett are:
> Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
>
>
> -

-Vadim Lobanov

Re: what's next for the linux kernel?

[Rik van Riel]

On Sun, 2 Oct 2005, Gene Heskett wrote:

> Ahh, yes and no, Robert.  The un-answered question, for that
> 512 processor Altix system, would be "but does it run things 512
> times faster?"  Methinks not, by a very wide margin.  Yes, do a lot
> of unrelated things fast maybe, but render a 30 megabyte page with
> ghostscript in 10 milliseconds?  Never happen IMO.

You haven't explained us why you think your proposal
would allow Linux to circumvent Amdahl's law...

-- 
All Rights Reversed

Re: what's next for the linux kernel?

[Gene Heskett]

On Sunday 02 October 2005 19:48, Rik van Riel wrote:
>On Sun, 2 Oct 2005, Gene Heskett wrote:
>> Ahh, yes and no, Robert.  The un-answered question, for that
>> 512 processor Altix system, would be "but does it run things 512
>> times faster?"  Methinks not, by a very wide margin.  Yes, do a lot
>> of unrelated things fast maybe, but render a 30 megabyte page with
>> ghostscript in 10 milliseconds?  Never happen IMO.
>
>You haven't explained us why you think your proposal
>would allow Linux to circumvent Amdahl's law...

Amdahl's Law?

Thats a reference I don't believe I've been made aware of.  Can you
elaborate?
  
Besides, it isn't my proposal, just a question in that I chose a
scenario (ghostscripts rendering of a page of text) that in fact only
runs maybe 10x faster on an XP-2800 Athlon with a gig of dram than it
did on my old 25 mhz 68040 equipt amiga with 64 megs of dram.  
With 64 megs of dram, so it wasn't nearly as memory bound doing that
as most of the Amiga's were.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.35% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Re: what's next for the linux kernel?

[Jesper Juhl]

On 10/3/05, Gene Heskett <gene.heskett@verizon.net> wrote:
> On Sunday 02 October 2005 19:48, Rik van Riel wrote:
> >On Sun, 2 Oct 2005, Gene Heskett wrote:
> >> Ahh, yes and no, Robert.  The un-answered question, for that
> >> 512 processor Altix system, would be "but does it run things 512
> >> times faster?"  Methinks not, by a very wide margin.  Yes, do a lot
> >> of unrelated things fast maybe, but render a 30 megabyte page with
> >> ghostscript in 10 milliseconds?  Never happen IMO.
> >
> >You haven't explained us why you think your proposal
> >would allow Linux to circumvent Amdahl's law...
>
> Amdahl's Law?
>
http://en.wikipedia.org/wiki/Amdahl's_law
http://home.wlu.edu/~whaleyt/classes/parallel/topics/amdahl.html

And google has even more. Wonderful thing those search engines...


--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: what's next for the linux kernel?

[Bodo Eggert]

Marc Perkel <marc@perkel.com> wrote:

[...]
> I'll run through a few ideas here.

> Novell Netware type permissions. ACLs are a step in the right direction
> but Linux isn't any where near where Novell was back in 1990. Linux lets
> you - for example - to delete files that you have no read or write
> access rights to.

It lets you unlink them. That's different from deleting, since the owner
may have his/her private link to that file.

Unlinking is changing the contents of a directory, and it's controlled by
the write permission of the containing directory.

> Netware on the other hand prevents you from deleting
> files that you can't write to and if you have no right it is as if the
> file isn't there.

Imagine a /tmp directory (writable by world) with user "a" creating a file
"foo", umask=077 and user "b" trying to do the same. User "b" will get
'file exists' if he tries to create it, and 'file does not exist' if he
tries to list it. He will go nuts.

BTW: YANI: That about a tmpfs where all-numerical entries can only be
created by the corresponding UID? This would provide a secure, private
tmp directory to each user without the possibility of races and denial-of-
service attacks. Maybe it should be controlled by a mount flag.

> You can't even see it in the directory. Netware also
> has inherited permissions like Windows and Samba has and this is doing
> it right.

You can't do that if you have hardlinks. However, I missed the feature of
overruling file permissions in some special directories, e.g. anything
put under /pub should ignore umask and be a+rX.

> File systems and individual directories should be able to be
> flagged as casesensitive/insensitive.

IMHO not needed.

> Permissions need to be fine
> grained and easy to use. Netware is a good example to emulate.

ACK.

> The bootup sequence of Linux is pathetic. What an ungodly mess.

Which one? The bsd-style, sysv-suse-style, the sysv-debian-style,
the sysv-gentoo-style, the supervise-style, ...?

> The
> FSTAB file needs to go and a smarter system needs to be developed.

Smarter than recognizing the partitions by GUID?

> I
> know this isn't entirely a kernel issue but it is somewhat related.
> 
> I think development needs to be done to make the kernel cleaner and
> smarter rather than just bigger and faster. It's time to look at what
> users need and try to make Linux somewhat more windows like in being
> able to smartly recover from problems.

Using "windows" and "smartly recover from problems" is strange.

> Perhaps better error messages

And it becomes even more strange. Decent error messsages from windows are
as common as snowballs in hell.

> that your traditional kernel panic or hex dump screen of death.

«Some error occured. Press "OK".»

And if there is a help button, it won't.

> The big challenge for Linux is to be able to put it in the hands of
> people who don't want to dedicate their entire life to understanding all
> the little quirks that we have become used to. The slogan should be
> "this just works" and is intuitive.

"Just working" isn't easy if you have zillions of dependencies and even
more possibilities to choose from. You can e.g. make linux use a raid0
of a network block device and a loop-mounted file accessed over a ssh
session as it's root device (just in case if you you got bored of drilling
holes into your knees, pooring milk into them and raising fish in them.)

-- 
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
verbreiteten Lügen zu sabotieren.

Re: what's next for the linux kernel?

[Luke Kenneth Casson Leighton]

On Wed, Oct 05, 2005 at 12:04:01AM +0200, Bodo Eggert wrote:
> > You can't even see it in the directory. Netware also
> > has inherited permissions like Windows and Samba has and this is doing
> > it right.
> 
> You can't do that if you have hardlinks. 

 nt 5.0 added hardlinks to ntfs.

Re: what's next for the linux kernel?

[Nix]

On 5 Oct 2005, Luke Kenneth Casson Leighton murmured woefully:
> On Wed, Oct 05, 2005 at 12:04:01AM +0200, Bodo Eggert wrote:
>> > You can't even see it in the directory. Netware also
>> > has inherited permissions like Windows and Samba has and this is doing
>> > it right.
>> 
>> You can't do that if you have hardlinks. 
> 
>  nt 5.0 added hardlinks to ntfs.

Actually they've been present from the start, but only accessible
through the POSIX subsystem and (IIRC) the Backup API (?!!)

-- 
`Next: FEMA neglects to take into account the possibility of
fire in Old Balsawood Town (currently in its fifth year of drought
and home of the General Grant Home for Compulsive Arsonists).'
            --- James Nicoll

Re: what's next for the linux kernel?

[Luke Kenneth Casson Leighton]

On Thu, Oct 06, 2005 at 12:12:49AM +0100, Nix wrote:
> On 5 Oct 2005, Luke Kenneth Casson Leighton murmured woefully:
> > On Wed, Oct 05, 2005 at 12:04:01AM +0200, Bodo Eggert wrote:
> >> > You can't even see it in the directory. Netware also
> >> > has inherited permissions like Windows and Samba has and this is doing
> >> > it right.
> >> 
> >> You can't do that if you have hardlinks. 
> > 
> >  nt 5.0 added hardlinks to ntfs.
> 
> Actually they've been present from the start, but only accessible
> through the POSIX subsystem and (IIRC) the Backup API (?!!)
 
 *hack* *cough* *choke* someone call 911. *thump* too late.

Re: what's next for the linux kernel?

[Nix]

On Thu, 6 Oct 2005, Luke Kenneth Casson Leighton said:
> On Thu, Oct 06, 2005 at 12:12:49AM +0100, Nix wrote:
>> On 5 Oct 2005, Luke Kenneth Casson Leighton murmured woefully:
>> >  nt 5.0 added hardlinks to ntfs.
>> 
>> Actually they've been present from the start, but only accessible
>> through the POSIX subsystem and (IIRC) the Backup API (?!!)
>  
>  *hack* *cough* *choke* someone call 911. *thump* too late.

I agree, it's barmy. (Cygwin, running under the Win32 subsystem as it
does, manipulates hardlinks via the Backup API.)

I assume the `logic' was that even though hardlinks were only there
for the sake of the mostly-useless POSIX subsystem, you still
might want to back them up...

-- 
`Next: FEMA neglects to take into account the possibility of
fire in Old Balsawood Town (currently in its fifth year of drought
and home of the General Grant Home for Compulsive Arsonists).'
            --- James Nicoll

Re: what's next for the linux kernel?

[Nix]

On 4 Oct 2005, Bodo Eggert stated:
> BTW: YANI: That about a tmpfs where all-numerical entries can only be
> created by the corresponding UID? This would provide a secure, private
> tmp directory to each user without the possibility of races and denial-of-
> service attacks. Maybe it should be controlled by a mount flag.

Wouldn't it be less kludgy to just use the existing private namespace
stuff to provide each user with its own /tmp? (Or each user's session,
rather, which is probably much easier, as that corresponds precisely to
one process tree).

-- 
`Next: FEMA neglects to take into account the possibility of
fire in Old Balsawood Town (currently in its fifth year of drought
and home of the General Grant Home for Compulsive Arsonists).'
            --- James Nicoll

Re: what's next for the linux kernel?

[Marc Perkel]

Nix wrote:

>On 4 Oct 2005, Bodo Eggert stated:
>  
>
>>BTW: YANI: That about a tmpfs where all-numerical entries can only be
>>created by the corresponding UID? This would provide a secure, private
>>tmp directory to each user without the possibility of races and denial-of-
>>service attacks. Maybe it should be controlled by a mount flag.
>>    
>>
>
>Wouldn't it be less kludgy to just use the existing private namespace
>stuff to provide each user with its own /tmp? (Or each user's session,
>rather, which is probably much easier, as that corresponds precisely to
>one process tree).
>
>  
>

If you were going to do it right here's what you would do:

People who had files in /tmp would have no rights at all to other users 
/tmp files.
Listing the dirtectory would only display the files you had some access 
to. If you have no rights you don't even see that the file is there.
The effect would be like giving people their own tmp directories.

-- 
Marc Perkel - marc@perkel.com

Spam Filter: http://www.junkemailfilter.com
    My Blog: http://marc.perkel.com

Re: what's next for the linux kernel?

[Lennart Sorensen]

On Wed, Oct 05, 2005 at 07:41:21AM -0700, Marc Perkel wrote:
> If you were going to do it right here's what you would do:
> 
> People who had files in /tmp would have no rights at all to other users 
> /tmp files.
> Listing the dirtectory would only display the files you had some access 
> to. If you have no rights you don't even see that the file is there.
> The effect would be like giving people their own tmp directories.

Except it still wouldn't be able to go: Does file xyz exist?  If not,
create file xyz.  If someone else had xyz that you didn't see, you would
still not be able to create it.  So what is the point of NOT showing it
other than to make it much harder to avoid conflicting names?

if you want to not see files that you have no rights to, filter it in
your user space application when it matters, and let user space see the
files when they need to in order to avoid name conflicts.

It would be an incredibly idiotic system that auto hides files just
because you can't use them.  We have ways to hide files in user space
for the convinience of users.  It would be too inconvinient for
applications if the OS hid files on us.

Len Sorensen

Re: what's next for the linux kernel?

[Marc Perkel]

Lennart Sorensen wrote:

>On Wed, Oct 05, 2005 at 07:41:21AM -0700, Marc Perkel wrote:
>  
>
>>If you were going to do it right here's what you would do:
>>
>>People who had files in /tmp would have no rights at all to other users 
>>/tmp files.
>>Listing the dirtectory would only display the files you had some access 
>>to. If you have no rights you don't even see that the file is there.
>>The effect would be like giving people their own tmp directories.
>>    
>>
>
>Except it still wouldn't be able to go: Does file xyz exist?  If not,
>create file xyz.  If someone else had xyz that you didn't see, you would
>still not be able to create it.  So what is the point of NOT showing it
>other than to make it much harder to avoid conflicting names?
>
>if you want to not see files that you have no rights to, filter it in
>your user space application when it matters, and let user space see the
>files when they need to in order to avoid name conflicts.
>
>It would be an incredibly idiotic system that auto hides files just
>because you can't use them.  We have ways to hide files in user space
>for the convinience of users.  It would be too inconvinient for
>applications if the OS hid files on us.
>
>Len Sorensen
>  
>

What is incredibly idiotic is a file system that allws you to delete 
files that you have no write access to. That is stupid beyond belief and 
only the Unix community doesn't get it.

-- 
Marc Perkel - marc@perkel.com

Spam Filter: http://www.junkemailfilter.com
    My Blog: http://marc.perkel.com

Re: what's next for the linux kernel?

[Lennart Sorensen]

On Wed, Oct 05, 2005 at 07:48:12AM -0700, Marc Perkel wrote:
> What is incredibly idiotic is a file system that allws you to delete 
> files that you have no write access to. That is stupid beyond belief and 
> only the Unix community doesn't get it.

If I have a directory and I want to remove it, I can almost always do
that.  The file only goes away if there are no other hardlinks to it.
If someone cares about the file, they should keep a hardlink to it in a
directory THEY own.

Directories within directories on the other hand can make things a pain
since if you don't own the subdir, you can't remove its contents, so you
can't remove it.  You could however likely move the dir somewhere else
to get it out of your way.

My directory is MY file and I get to do whatever I want to it.  Who
knows how someone else managed to get a file into it in the first place.

/tmp is of course different since it has the bit turned on that says
only the file owner can delete it.  If you want that enabled on all
directories, go ahead.  It is supported, although who knows what
applications that might break.  unix supports both ways of directory
behaviour after all.  It isn't one way or the other.

Len Sorensen

Re: what's next for the linux kernel?

[Marc Perkel]

Lennart Sorensen wrote:

>On Wed, Oct 05, 2005 at 07:48:12AM -0700, Marc Perkel wrote:
>  
>
>>What is incredibly idiotic is a file system that allws you to delete 
>>files that you have no write access to. That is stupid beyond belief and 
>>only the Unix community doesn't get it.
>>    
>>
>
>If I have a directory and I want to remove it, I can almost always do
>that.  The file only goes away if there are no other hardlinks to it.
>If someone cares about the file, they should keep a hardlink to it in a
>directory THEY own.
>
>Directories within directories on the other hand can make things a pain
>since if you don't own the subdir, you can't remove its contents, so you
>can't remove it.  You could however likely move the dir somewhere else
>to get it out of your way.
>
>My directory is MY file and I get to do whatever I want to it.  Who
>knows how someone else managed to get a file into it in the first place.
>
>/tmp is of course different since it has the bit turned on that says
>only the file owner can delete it.  If you want that enabled on all
>directories, go ahead.  It is supported, although who knows what
>applications that might break.  unix supports both ways of directory
>behaviour after all.  It isn't one way or the other.
>
>Len Sorensen
>  
>

Agian - thinking outside the box.

If the permissions were don'e right in your own directories your 
inherited rights would give your permissions automatically to your home 
directory and all directories uner it. Netware has a concept called an 
inherited rights mask - something Linux lacks. Windows also has rights 
like this and Samba emulates it. So unless root put files in your 
directory and specifically denied you rights to them, you would have 
full rights to your own directory.

However - if you were browsing the /etc directory and there were files 
there that you had no read or write access to - then you wouldn't even 
be able to list them. If you went to the home directory and lets say 
everyone had 700 permissions on all the directories withing home, you 
would only see your own directory. You wouldn't even be able to know 
what other directories existed there.

If you want to start thinking about DOING IT RIGHT you need to think 
beyond the Unix model and start looking at Netware. Maybe in 5 years 
Linux will evolve to where Netware was in 1990.

Unix permissions totally suck but it's old baggage that you're stuck 
with somewhat. Are you going to be stuck forever and is Linux ever going 
to grow up and move on to better things? Linux is crippled when it comes 
to permissions. The Windows people are laughing at you and you don't 
even get it why they are laughing.

-- 
Marc Perkel - marc@perkel.com

Spam Filter: http://www.junkemailfilter.com
    My Blog: http://marc.perkel.com

Re: what's next for the linux kernel?

[Lennart Sorensen]

On Wed, Oct 05, 2005 at 08:08:26AM -0700, Marc Perkel wrote:
> Agian - thinking outside the box.
> 
> If the permissions were don'e right in your own directories your 
> inherited rights would give your permissions automatically to your home 
> directory and all directories uner it. Netware has a concept called an 
> inherited rights mask - something Linux lacks. Windows also has rights 
> like this and Samba emulates it. So unless root put files in your 
> directory and specifically denied you rights to them, you would have 
> full rights to your own directory.

Well I could have setup my home dirs with ACL to have inherited rights
to all files created under it for the owner.  Well I didn't but then
again I don't allow other people to write to my home dir so it hasn't
been a problem.

> However - if you were browsing the /etc directory and there were files 
> there that you had no read or write access to - then you wouldn't even 
> be able to list them. If you went to the home directory and lets say 
> everyone had 700 permissions on all the directories withing home, you 
> would only see your own directory. You wouldn't even be able to know 
> what other directories existed there.

Well I don't have write access to /etc so who cares.  I do have write
access to /tmp and there is matters that I can list files I have no
access to.  Hence why /tmp IS readable by all.  If I couldn't list files
there I would have to randomly try filenames until I found one that
wasn't already in use but invisible to me due to idiot magic.

What error does netware return if you try to create a file in a
directory that already exists but which you can't see?  Any error would
be indirectly a way to see the file, so it should have just been visible
in the first place.

> If you want to start thinking about DOING IT RIGHT you need to think 
> beyond the Unix model and start looking at Netware. Maybe in 5 years 
> Linux will evolve to where Netware was in 1990.

NetWare was not the be all and end all of filesystems.  Far from it.  It
had some good points, but it certainly didn't solve everything.

> Unix permissions totally suck but it's old baggage that you're stuck 
> with somewhat. Are you going to be stuck forever and is Linux ever going 
> to grow up and move on to better things? Linux is crippled when it comes 
> to permissions. The Windows people are laughing at you and you don't 
> even get it why they are laughing.

I find unix permissions work great in general, and for complex things
posix ACL has done everything I wanted it to and works great with samba.

The behaviours you claim are so great in netware to me seem like things
I would very much NOT want to have to deal with.  I like things simple
enough to understand them so I can make sure they are right.

Len Sorensen

Re: what's next for the linux kernel?

[Nix]

On Wed, 05 Oct 2005, Marc Perkel yowled:
> Agian - thinking outside the box.

I hate that phrase. There is no `box'.

> If the permissions were don'e right in your own directories your
> inherited rights would give your permissions automatically to your
> home directory and all directories uner it. Netware has a concept
> called an inherited rights mask - something Linux lacks. Windows also
> has rights like this and Samba emulates it. So unless root put files
> in your directory and specifically denied you rights to them, you
> would have full rights to your own directory.

So, um, what happens to these permissions when you copy a file and put
it somewhere else? Do the inherited rights go with it or not? In Unix
it's pretty intuitive. In this system there seem to be two right
answers, both of which seem... risky from a security perspective.

> However - if you were browsing the /etc directory and there were files
> there that you had no read or write access to - then you wouldn't even
> be able to list them.

/tmp is the problem here, and shows the futility and pointlessness of
this feature. If you have an unlistable file in /tmp, *its name is still
determinable*, because other users cannot create files with that
name. The concept adds *nothing* over some combination of dirs with the
execute bit cleared for some set of users and subdirectories which
cannot be read by some set of users. There's no need for this profoundly
non-Unixlike permission at all. (As usual, ACLs make managing this on
a fine-grained scale rather easier.)

>                       If you went to the home directory and lets say
> everyone had 700 permissions on all the directories withing home, you
> would only see your own directory. You wouldn't even be able to know
> what other directories existed there.

This is what per-process filesystems are for.

> If you want to start thinking about DOING IT RIGHT you need to think
> beyond the Unix model and start looking at Netware. Maybe in 5 years
> Linux will evolve to where Netware was in 1990.

I think Plan 9 is a better goal than Netware. At least it was designed
by people aiming for a better Unix rather than people trying to build a
better DOS, and so is more likely to have a compatible philosophy.

> Unix permissions totally suck but it's old baggage that you're stuck
> with somewhat. Are you going to be stuck forever and is Linux ever
> going to grow up and move on to better things? Linux is crippled when
> it comes to permissions.

Well, you can't change it drastically without violating POSIX. There's
no damned way Linux is going to do *that*.

>                          The Windows people are laughing at you and
> you don't even get it why they are laughing.

You *do* realise just how incapable the Windows permission-management
GUI is, don't you? Any OS where the command-line tools hide half
the permissions model and the GUI hides a slightly different half,
and where looking at a set of permissions and hitting cancel can
*change* those permissions drastically, is not sane.

(Disclaimer: the last time I bothered to verify the latter behaviour
was in NT4. Maybe they've partially fixed it.)

-- 
`Next: FEMA neglects to take into account the possibility of
fire in Old Balsawood Town (currently in its fifth year of drought
and home of the General Grant Home for Compulsive Arsonists).'
            --- James Nicoll

Re: what's next for the linux kernel?

[Marc Perkel]

Nix wrote:

>On Wed, 05 Oct 2005, Marc Perkel yowled:
>  
>
>>Agian - thinking outside the box.
>>    
>>
>
>I hate that phrase. There is no `box'.
>
>  
>
That's what it looks like when you are inside it.

>>If the permissions were don'e right in your own directories your
>>inherited rights would give your permissions automatically to your
>>home directory and all directories uner it. Netware has a concept
>>called an inherited rights mask - something Linux lacks. Windows also
>>has rights like this and Samba emulates it. So unless root put files
>>in your directory and specifically denied you rights to them, you
>>would have full rights to your own directory.
>>    
>>
>
>So, um, what happens to these permissions when you copy a file and put
>it somewhere else? Do the inherited rights go with it or not? In Unix
>it's pretty intuitive. In this system there seem to be two right
>answers, both of which seem... risky from a security perspective.
>  
>
You inherit the rights of the new directory.

Also - under Netware not all permissions are stored with the file. The 
rights are calculated from the file heirachy so you don't store a lot of 
data with each file unless the file has permissions set that is 
different than that of the directory it's in. So moving a file to 
someone's home directory doesn't require any permissions to be set to 
give the user rights to the file.

>  
>
>>However - if you were browsing the /etc directory and there were files
>>there that you had no read or write access to - then you wouldn't even
>>be able to list them.
>>    
>>
>
>/tmp is the problem here, and shows the futility and pointlessness of
>this feature. If you have an unlistable file in /tmp, *its name is still
>determinable*, because other users cannot create files with that
>name. The concept adds *nothing* over some combination of dirs with the
>execute bit cleared for some set of users and subdirectories which
>cannot be read by some set of users. There's no need for this profoundly
>non-Unixlike permission at all. (As usual, ACLs make managing this on
>a fine-grained scale rather easier.)
>
>  
>
It doesn't really make sense to use the /tmp directory the way Unix uses 
it. Why would you want just anyone to even know the names of the 
temporary files you are using. Users should have their own temp 
directory or create their own directory within /tmp

But - to address your question - if there were an invisible (to you) 
file in a directory that you had create rights to then you would get a 
file creation error.

>>                      If you went to the home directory and lets say
>>everyone had 700 permissions on all the directories withing home, you
>>would only see your own directory. You wouldn't even be able to know
>>what other directories existed there.
>>    
>>
>
>This is what per-process filesystems are for.
>
>  
>
>>If you want to start thinking about DOING IT RIGHT you need to think
>>beyond the Unix model and start looking at Netware. Maybe in 5 years
>>Linux will evolve to where Netware was in 1990.
>>    
>>
>
>I think Plan 9 is a better goal than Netware. At least it was designed
>by people aiming for a better Unix rather than people trying to build a
>better DOS, and so is more likely to have a compatible philosophy.
>
>  
>
I'm not familiar with Plan 9.

>>Unix permissions totally suck but it's old baggage that you're stuck
>>with somewhat. Are you going to be stuck forever and is Linux ever
>>going to grow up and move on to better things? Linux is crippled when
>>it comes to permissions.
>>    
>>
>
>Well, you can't change it drastically without violating POSIX. There's
>no damned way Linux is going to do *that*.
>
>  
>
>>                         The Windows people are laughing at you and
>>you don't even get it why they are laughing.
>>    
>>
>
>You *do* realise just how incapable the Windows permission-management
>GUI is, don't you? Any OS where the command-line tools hide half
>the permissions model and the GUI hides a slightly different half,
>and where looking at a set of permissions and hitting cancel can
>*change* those permissions drastically, is not sane.
>  
>
That's why I'm pushing netware as a model rather than windows. But 
Windows file permissions are superior to Linux.

>(Disclaimer: the last time I bothered to verify the latter behaviour
>was in NT4. Maybe they've partially fixed it.)
>
>  
>

One place where Windows wins over Linux is in the "easy to use" 
category. Something the Linux world should look ast.

I am a Linux supporter and love it. I'm saying this to help make it better.

-- 
Marc Perkel - marc@perkel.com

Spam Filter: http://www.junkemailfilter.com
    My Blog: http://marc.perkel.com

Re: what's next for the linux kernel?

[Nix]

On Wed, 05 Oct 2005, Marc Perkel stipulated:
> Nix wrote:
>>On Wed, 05 Oct 2005, Marc Perkel yowled:
>>So, um, what happens to these permissions when you copy a file and put
>>it somewhere else? Do the inherited rights go with it or not? In Unix
>>it's pretty intuitive. In this system there seem to be two right
>>answers, both of which seem... risky from a security perspective.
>
> You inherit the rights of the new directory.

That's a hugely counterintuitive potential security hole in waiting.

Because any number of permissions can be inherited (anything from none
of them, to all of them), this means that upon copying a file *you
cannot reliably tell what its permissions will become* without checking
it.

I don't think I need to point out the flaw in such a scheme.

> Also - under Netware not all permissions are stored with the file. The
> rights are calculated from the file heirachy so you don't store a lot
> of data with each file unless the file has permissions set that is
> different than that of the directory it's in. So moving a file to
> someone's home directory doesn't require any permissions to be set to
> give the user rights to the file.

I consider this a substantial *disadvantage*. Changing permissions should
be something that you have to explicitly do: it shouldn't happen quietly
behind your back merely on account of a rename().

>>/tmp is the problem here, and shows the futility and pointlessness of
>>this feature. If you have an unlistable file in /tmp, *its name is still
>>determinable*, because other users cannot create files with that
>>name. The concept adds *nothing* over some combination of dirs with the
>>execute bit cleared for some set of users and subdirectories which
>>cannot be read by some set of users. There's no need for this profoundly
>>non-Unixlike permission at all. (As usual, ACLs make managing this on
>>a fine-grained scale rather easier.)
>
> It doesn't really make sense to use the /tmp directory the way Unix
> uses it. Why would you want just anyone to even know the names of the
> temporary files you are using. Users should have their own temp
> directory or create their own directory within /tmp

This is what per-process namespaces are for.

> But - to address your question - if there were an invisible (to you)
> file in a directory that you had create rights to then you would get a
> file creation error.

i.e., the filename is *not* invisible, but trivially determinable by a
sufficiently determined attacker; sticking the file in a non-readable
directory is doable *now*, and *already* lacks this weakness.

i.e., the feature is useless.

>>I think Plan 9 is a better goal than Netware. At least it was designed
>>by people aiming for a better Unix rather than people trying to build a
>>better DOS, and so is more likely to have a compatible philosophy.
>>
> I'm not familiar with Plan 9.

Linux seems to be stealing all its good ideas bit by bit, so you'll
know sooner or later. :)

But per-process namespaces are *wonderful*. Goodbye, PATH, for instance:
just mount every binary this user should see in this user's /bin. He
gets his own /tmp, and /home contains *his home directory*.

(Special considerations have to be made for privileged processes: we
don't want the user to be able to fake them out by fooling with /etc,
say, or with their shared libraries. Perhaps setuid programs revert to a
standard namespace, and can see the user's one in
/proc/self/nonprivileged-root or something.)

-- 
`Next: FEMA neglects to take into account the possibility of
fire in Old Balsawood Town (currently in its fifth year of drought
and home of the General Grant Home for Compulsive Arsonists).'
            --- James Nicoll

Re: what's next for the linux kernel?

[Denis Vlasenko]

On Wednesday 05 October 2005 22:30, Marc Perkel wrote:
> >So, um, what happens to these permissions when you copy a file and put
> >it somewhere else? Do the inherited rights go with it or not? In Unix
> >it's pretty intuitive. In this system there seem to be two right
> >answers, both of which seem... risky from a security perspective.
> >  
> >
> You inherit the rights of the new directory.
> 
> Also - under Netware not all permissions are stored with the file. The 
> rights are calculated from the file heirachy so you don't store a lot of 
> data with each file unless the file has permissions set that is 

Since when 16 bits is a lot of data?

> different than that of the directory it's in. So moving a file to 
> someone's home directory doesn't require any permissions to be set to 
> give the user rights to the file.
> 
> >/tmp is the problem here, and shows the futility and pointlessness of
> >this feature. If you have an unlistable file in /tmp, *its name is still
> >determinable*, because other users cannot create files with that
> >name. The concept adds *nothing* over some combination of dirs with the
> >execute bit cleared for some set of users and subdirectories which
> >cannot be read by some set of users. There's no need for this profoundly
> >non-Unixlike permission at all. (As usual, ACLs make managing this on
> >a fine-grained scale rather easier.)
> >
> It doesn't really make sense to use the /tmp directory the way Unix uses 
> it. Why would you want just anyone to even know the names of the 
> temporary files you are using. Users should have their own temp 
> directory or create their own directory within /tmp

Then use ~/tmp in your homedir. What's the problem?

> >You *do* realise just how incapable the Windows permission-management
> >GUI is, don't you? Any OS where the command-line tools hide half
> >the permissions model and the GUI hides a slightly different half,
> >and where looking at a set of permissions and hitting cancel can
> >*change* those permissions drastically, is not sane.
> >  
> >
> That's why I'm pushing netware as a model rather than windows. But 
> Windows file permissions are superior to Linux.
> 
> >(Disclaimer: the last time I bothered to verify the latter behaviour
> >was in NT4. Maybe they've partially fixed it.)
> 
> One place where Windows wins over Linux is in the "easy to use" 
> category. Something the Linux world should look ast.

"Easy to use" to whom?

Command line tools for changing permissions under Windows are anything
but "easy to use". They are also feature incomplete. Tools for changing
ownership do not exist at all. Tools for changing permissions/ownership
on registry do not exist also. Maybe third party ones exist, dunno.
Every one that I saw on the Inet, was either buggy, incomplete, or both.

For admins, this is a huge hole in usability.

> I am a Linux supporter and love it. I'm saying this to help make it better.
--
vda

Re: what's next for the linux kernel?

[Al Viro]

On Wed, Oct 05, 2005 at 08:16:19PM +0100, Nix wrote:
> On Wed, 05 Oct 2005, Marc Perkel yowled:
> > If you want to start thinking about DOING IT RIGHT you need to think
> > beyond the Unix model and start looking at Netware. Maybe in 5 years
> > Linux will evolve to where Netware was in 1990.

Ugly as hell and thankfully about to go extinct outside of dark places
where its malignant presense still lingers amidst the Shoggoth droppings?

> I think Plan 9 is a better goal than Netware. At least it was designed
> by people aiming for a better Unix rather than people trying to build a
> better DOS, and so is more likely to have a compatible philosophy.

s/aiming.*/with taste that doesn't belong in R'Lyeh/

Re: what's next for the linux kernel?

[Marc Perkel]

Al Viro wrote:

>On Wed, Oct 05, 2005 at 08:16:19PM +0100, Nix wrote:
>  
>
>>On Wed, 05 Oct 2005, Marc Perkel yowled:
>>    
>>
>>>If you want to start thinking about DOING IT RIGHT you need to think
>>>beyond the Unix model and start looking at Netware. Maybe in 5 years
>>>Linux will evolve to where Netware was in 1990.
>>>      
>>>
>
>Ugly as hell and thankfully about to go extinct outside of dark places
>where its malignant presense still lingers amidst the Shoggoth droppings?
>
>  
>
The big boys are still running Netware because Linux doesn't do the 
things they need netware to do. And Netware isn't going away until Linux 
has the power to replace it. Linux permissions acient and awkward. 
Netware is wonderful. Linux is crippled. Linux needs to modernize.

Re: what's next for the linux kernel?

[Lennart Sorensen]

On Wed, Oct 05, 2005 at 12:49:12PM -0700, Marc Perkel wrote:
> The big boys are still running Netware because Linux doesn't do the 
> things they need netware to do. And Netware isn't going away until Linux 
> has the power to replace it. Linux permissions acient and awkward. 
> Netware is wonderful. Linux is crippled. Linux needs to modernize.

Netware is a fileserver for windows/dos/os2, linux is an operating
system for running applications.  Being able to serve files to other
systems is just one potential application to run on linux but it has
plenty of other things it can do.

People that need netware are people that need a fileserver for their
windows systems.  Linux is probably not what they need then.

Len Sorensen

Re: what's next for the linux kernel?

[linux-os (Dick Johnson)]

On Wed, 5 Oct 2005, Al Viro wrote:

> On Wed, Oct 05, 2005 at 08:16:19PM +0100, Nix wrote:
>> On Wed, 05 Oct 2005, Marc Perkel yowled:
>>> If you want to start thinking about DOING IT RIGHT you need to think
>>> beyond the Unix model and start looking at Netware. Maybe in 5 years
>>> Linux will evolve to where Netware was in 1990.
>
> Ugly as hell and thankfully about to go extinct outside of dark places
> where its malignant presense still lingers amidst the Shoggoth droppings?
>
>> I think Plan 9 is a better goal than Netware. At least it was designed
>> by people aiming for a better Unix rather than people trying to build a
>> better DOS, and so is more likely to have a compatible philosophy.
>
> s/aiming.*/with taste that doesn't belong in R'Lyeh/
>

Excuse me but wasn't Netware the DOS server that started as
a corrupted BSD Unix system, purposely obfuscated to prevent
prying eyes from discovering that it was an unauthorized Unix
variant?

Or was it really a variant of the defunct Xerox XNS that claimed
that they created SPX/IPX?


Cheers,
Dick Johnson
Penguin : Linux version 2.6.13 on an i686 machine (5589.55 BogoMips).
Warning : 98.36% of all statistics are fiction.

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: what's next for the linux kernel?

[Nix]

On Wed, 05 Oct 2005, Marc Perkel announced authoritatively:
> If the permissions were don'e right in your own directories your
> inherited rights would give your permissions automatically to your
> home directory and all directories uner it. Netware has a concept
> called an inherited rights mask - something Linux lacks. Windows also
> has rights like this and Samba emulates it. So unless root put files
> in your directory and specifically denied you rights to them, you
> would have full rights to your own directory.

I quite forgot the most grotesque problem with this, which in my opinion
completely eliminates the possibility of inherited permissions on any
even vaguely-POSIX-like system.

What happens if you have a file with two links in directories with
different inheritable permissions set? What are its permissions now?
Surely it doesn't depend on where you happened to open it from!

-- 
`Next: FEMA neglects to take into account the possibility of
fire in Old Balsawood Town (currently in its fifth year of drought
and home of the General Grant Home for Compulsive Arsonists).'
            --- James Nicoll

Re: what's next for the linux kernel?

[Nigel Rantor]

Marc Perkel wrote:
> 
> What is incredibly idiotic is a file system that allws you to delete 
> files that you have no write access to. That is stupid beyond belief and 
> only the Unix community doesn't get it.

No.

What's idiotic is leaving your property (files) on someone elses desk 
(directory) and expecting them always to be there when you come back.

   n

Re: what's next for the linux kernel?

[Bodo Eggert]

On Wed, 5 Oct 2005, Marc Perkel wrote:

> What is incredibly idiotic is a file system that allws you to delete 
> files that you have no write access to. That is stupid beyond belief and 
> only the Unix community doesn't get it.

1) Unlinking is not deleting, it may just trigger deleting. !Unix people 
   don't get it.

   If you like non-owners to have no unlink permission, you have to set 
   the sticky bit. If you want other users not to be able to delete files
   you put into a public directory, put a link into that directory and 
   keep one in a private directory.

2) If you're accounted for the space occupied by your directories, you 
   need the permission to remove the directory. Otherwise you could DoS 
   other users if you have write permission in one of his directories.

-- 
Funny quotes:
29. When someone asks you, "A penny for your thoughts" and you put your two
    cents in . . . what happens to the other penny?

Re: what's next for the linux kernel?

[Florin Malita]

On Wed, 05 Oct 2005 07:48:12 -0700
Marc Perkel <marc@perkel.com> wrote:
> What is incredibly idiotic is a file system that allws you to delete 
> files that you have no write access to. That is stupid beyond belief and 
> only the Unix community doesn't get it.

It stops being idiotic as soon as you realize that _deleting_ a
file doesn't involve _writing_ to it in any way. It's not about UNIX,
it's about common sense - try thinking outside of the Netware box for a
sec ;)

Florin

Re: what's next for the linux kernel?

[Marc Perkel]

Florin Malita wrote:

>On Wed, 05 Oct 2005 07:48:12 -0700
>Marc Perkel <marc@perkel.com> wrote:
>  
>
>>What is incredibly idiotic is a file system that allws you to delete 
>>files that you have no write access to. That is stupid beyond belief and 
>>only the Unix community doesn't get it.
>>    
>>
>
>It stops being idiotic as soon as you realize that _deleting_ a
>file doesn't involve _writing_ to it in any way. It's not about UNIX,
>it's about common sense - try thinking outside of the Netware box for a
>sec ;)
>
>Florin
>  
>
What you don't get is that if you don't have rights to write to a file 
then you shouldn't have the right to delete the file.  Once you get past 
the "inside the box" Unix thinking you'll see the logic in this. So what 
if the process of deleting a file involves writing to it. That's not 
relevant.

-- 
Marc Perkel - marc@perkel.com

Spam Filter: http://www.junkemailfilter.com
    My Blog: http://marc.perkel.com

Re: what's next for the linux kernel?

[Lennart Sorensen]

On Wed, Oct 05, 2005 at 12:44:25PM -0700, Marc Perkel wrote:
> What you don't get is that if you don't have rights to write to a file 
> then you shouldn't have the right to delete the file.  Once you get past 
> the "inside the box" Unix thinking you'll see the logic in this. So what 
> if the process of deleting a file involves writing to it. That's not 
> relevant.

When a system supports hardlinks, it IS relevant.

So if I decide I want a link to a file like say /etc/group in my home
dir (let us pretend they are on the same partition) so I make a hardlink
to it in my home dir and end up with a file still owned by root (since I
shouldn't be able to add me as owner to the file just by linking to it
after all).  Should I now have to go bother the admin about deleting the
file from my home dir if I decide that wasn't really what I wanted?  If
I didn't have write permissions to the dir I wouldn't have been able to
make the link in the first place, so since I made it I should be able to
delete it, and I can with the unix way of doing things.  I still can't
edit it anymore than I could in the original place since it linked with
the new link to the file having the excact same permissions as the
original.  Only someone like root can go chance the owner of a hardlink
to someone else and start setting up some interesting file permissions
using multiple hardlinks to one file.

I suspect you can't do that on netware, so you would have to add
explicit permissions for each user to a single copy of the file instead,
and you would probably want them all to have read/write access but in
fact NOT have delete permissions.

Len Sorensen

Re: what's next for the linux kernel?

[Marc Perkel]

Lennart Sorensen wrote:

>On Wed, Oct 05, 2005 at 12:44:25PM -0700, Marc Perkel wrote:
>  
>
>>What you don't get is that if you don't have rights to write to a file 
>>then you shouldn't have the right to delete the file.  Once you get past 
>>the "inside the box" Unix thinking you'll see the logic in this. So what 
>>if the process of deleting a file involves writing to it. That's not 
>>relevant.
>>    
>>
>
>When a system supports hardlinks, it IS relevant.
>
>So if I decide I want a link to a file like say /etc/group in my home
>dir (let us pretend they are on the same partition) so I make a hardlink
>to it in my home dir and end up with a file still owned by root (since I
>shouldn't be able to add me as owner to the file just by linking to it
>after all).  Should I now have to go bother the admin about deleting the
>file from my home dir if I decide that wasn't really what I wanted?  If
>I didn't have write permissions to the dir I wouldn't have been able to
>make the link in the first place, so since I made it I should be able to
>delete it, and I can with the unix way of doing things.  I still can't
>edit it anymore than I could in the original place since it linked with
>the new link to the file having the excact same permissions as the
>original.  Only someone like root can go chance the owner of a hardlink
>to someone else and start setting up some interesting file permissions
>using multiple hardlinks to one file.
>
>I suspect you can't do that on netware, so you would have to add
>explicit permissions for each user to a single copy of the file instead,
>and you would probably want them all to have read/write access but in
>fact NOT have delete permissions.
>
>Len Sorensen
>  
>
What you don't understand is that Netware's permissions mechanish is 
totally different that Linux. A hard link in Netware wouldn't inherit 
rights the way Linux does. So the user would have rights to their hard 
link to delete that link without having rights to unlink the file.

This is an important concept so pay attention. Linux stores all the 
permission to a file with that file entry. Netware doesn't. Netware 
calculates effective rights from the parent directories and it is all 
inherited unless files or directoies are explicitly set differently. So 
if files are added to other people folders then those people get rights 
to it automatically without having to go to the second step of changing 
the file's permissions.


-- 
Marc Perkel - marc@perkel.com

Spam Filter: http://www.junkemailfilter.com
    My Blog: http://marc.perkel.com

Re: what's next for the linux kernel?

[Lennart Sorensen]

On Wed, Oct 05, 2005 at 01:05:30PM -0700, Marc Perkel wrote:
> What you don't understand is that Netware's permissions mechanish is 
> totally different that Linux. A hard link in Netware wouldn't inherit 
> rights the way Linux does. So the user would have rights to their hard 
> link to delete that link without having rights to unlink the file.
> 
> This is an important concept so pay attention. Linux stores all the 
> permission to a file with that file entry. Netware doesn't. Netware 
> calculates effective rights from the parent directories and it is all 
> inherited unless files or directoies are explicitly set differently. So 
> if files are added to other people folders then those people get rights 
> to it automatically without having to go to the second step of changing 
> the file's permissions.

So if you were to moint a partition on /mnt, does the mounted thing now
have to inherit permissions from / and /mnt or from it's own root or
what?

If you chroot something, does it have access to checking permissions
past it's 'virtual' root?

Can users make hardlinks themselves on netware or does an admin have to
do it?

It seems rather inefficient to have to read 8 directories worth of
permissions and calculate them together if you have a file 8 directories
deep compared to doing a single read and compare against a 16bit value +
uid/gid check (ACL of course makes this more complex, but still only
involves reading permissions in one place since inherited permissions
are for create time, not access time).

Unix offers features netware doesn't and some of them require
permissions to work a certain way.

Len Sorensen

Re: what's next for the linux kernel?

[Horst von Brand]

Marc Perkel <marc@perkel.com> wrote:

[...]

> What you don't understand is that Netware's permissions mechanish is
> totally different that Linux. A hard link in Netware wouldn't inherit
> rights the way Linux does. So the user would have rights to their hard
> link to delete that link without having rights to unlink the file.

OK, so a "hard link" isn't (because it has separate permissions than the
original). Sorry, watered-down symlinks don't cut it. Or just by linking
the file into my place I now have rights to modify it? The later idea makes
my skin try to crawl away...

> This is an important concept so pay attention. Linux stores all the
> permission to a file with that file entry.

You are completely right: This is an extremely central concept to
everything Unix.

>                                            Netware doesn't. Netware
> calculates effective rights from the parent directories and it is all
> inherited unless files or directoies are explicitly set
> differently. So if files are added to other people folders then those
> people get rights to it automatically without having to go to the
> second step of changing the file's permissions.

Which is a very clear explanation of how broken it all is. No wonder
NetWare is no more. Files whose persmissions change depending on which way
you look at them is a nightmare. Sure, you /can/ manage that for small(ish)
setups by brute force, but it soon has to break down.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: what's next for the linux kernel?

[Marc Perkel]

Horst von Brand wrote:

>Marc Perkel <marc@perkel.com> wrote:
>
>[...]
>
>  
>
>>What you don't understand is that Netware's permissions mechanish is
>>totally different that Linux. A hard link in Netware wouldn't inherit
>>rights the way Linux does. So the user would have rights to their hard
>>link to delete that link without having rights to unlink the file.
>>    
>>
>
>OK, so a "hard link" isn't (because it has separate permissions than the
>original). Sorry, watered-down symlinks don't cut it. Or just by linking
>the file into my place I now have rights to modify it? The later idea makes
>my skin try to crawl away...
>
>  
>
>>This is an important concept so pay attention. Linux stores all the
>>permission to a file with that file entry.
>>    
>>
>
>You are completely right: This is an extremely central concept to
>everything Unix.
>
>  
>
>>                                           Netware doesn't. Netware
>>calculates effective rights from the parent directories and it is all
>>inherited unless files or directoies are explicitly set
>>differently. So if files are added to other people folders then those
>>people get rights to it automatically without having to go to the
>>second step of changing the file's permissions.
>>    
>>
>
>Which is a very clear explanation of how broken it all is. No wonder
>NetWare is no more. Files whose persmissions change depending on which way
>you look at them is a nightmare. Sure, you /can/ manage that for small(ish)
>setups by brute force, but it soon has to break down.
>  
>
If you all think Netware is no more you are under an interesting 
illusion. Linux being cheap has cut into the little server market - but 
if you have thousands of servers all running off the same shared 
permissions systems - you just aren't going to do that off of Linux.

-- 
Marc Perkel - marc@perkel.com

Spam Filter: http://www.junkemailfilter.com
    My Blog: http://marc.perkel.com

Please STOP ! [was: what's next for the linux kernel?]

[Willy Tarreau]

[Cc: list purged to save people time]

On Wed, Oct 05, 2005 at 08:50:54PM -0700, Marc Perkel wrote:
> If you all think Netware is no more you are under an interesting 
> illusion. Linux being cheap has cut into the little server market - but 
> if you have thousands of servers all running off the same shared 
> permissions systems - you just aren't going to do that off of Linux.

Please will you move those boring threads to another mailing list or
even to usenet ? This is LKML, we're only the 6th of the month and
there are already 1250 messages, 200 of which come from this thread,
and many others coming from other long off-topic threads. 20% noise
is too high and disturbting. It becomes difficult to find someone
talking about subjects related to kernel development !

Thanks in advance
Willy

(NB: I'm not interested in your reply, so please don't Cc: me)

[VERY-OT SCOX Crap] [was: what's next for the linux kernel?]

[jmerkey]

Willy Tarreau wrote:

>[Cc: list purged to save people time]
>
>On Wed, Oct 05, 2005 at 08:50:54PM -0700, Marc Perkel wrote:
>  
>
>>If you all think Netware is no more you are under an interesting 
>>illusion. Linux being cheap has cut into the little server market - but 
>>if you have thousands of servers all running off the same shared 
>>permissions systems - you just aren't going to do that off of Linux.
>>    
>>

NetWhere? did you say. Oh yeah, that broken down piece of sh_t I rewrote 
10 years ago?
The NetWhere-did-its-market-share-go operating system is dead.

>
>Please will you move those boring threads to another mailing list or
>even to usenet ? This is LKML, we're only the 6th of the month and
>there are already 1250 messages, 200 of which come from this thread,
>and many others coming from other long off-topic threads. 20% noise
>is too high and disturbting. It becomes difficult to find someone
>talking about subjects rouelated to kernel development !
>
>  
>

You should move it to the "entertainment and trolling" section the Linux 
Community. Just add the
word "merkey" somewhere in the body of the text and forward it to the 
SCOX message board.
The thread will go on for days, and George Bush, Jimbo Wales, and even 
Sollog will probably join
the discussion.

:-)

>Thanks in advance
>Willy
>
>(NB: I'm not interested in your reply, so please don't Cc: me)
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>
>  
>

Re: what's next for the linux kernel?

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1085 bytes --]

On Wed, 05 Oct 2005 12:44:25 PDT, Marc Perkel said:
> What you don't get is that if you don't have rights to write to a file 
> then you shouldn't have the right to delete the file.  Once you get past 
> the "inside the box" Unix thinking you'll see the logic in this. So what 
> if the process of deleting a file involves writing to it. That's not 
> relevant.

Oddly enough, killfiles are *also* based on the concept of removing something
without the need or ability to look at the contents....

*plonk*

(Real-world analogy - if you've *ever* thrown away a box of anything without
opening the box, you understand that you don't need to be able to modify the
box to discard it.  The space enclosed by your domicile is basically read/write,
the box can be read-only and still end up in the dumpster.  On the other hand,
discarding the back staircase is a lot harder, as the frame of the house is
basically read-only, and you need to make it read-write in order to remove the
attachment points of the staircase.  Any Joe Sixpack carpenter understands this
to be entirely intuitive...)

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: what's next for the linux kernel?

[Dave Neuer]

On 10/5/05, Marc Perkel <marc@perkel.com> wrote:
>
> What you don't get is that if you don't have rights to write to a file
> then you shouldn't have the right to delete the file.  Once you get past
> the "inside the box" Unix thinking you'll see the logic in this. So what
> if the process of deleting a file involves writing to it. That's not
> relevant.
>

No. Listen to what other people are saying. If you have the right to
_create_ the file, you have the right to _delete_ the file. In one
case you are changing the state of where something is stored --
leaving your report on a desk. Changing the contents of the report is
different.

You may not like this paradigm, but it is the Unix/POSIX paradigm and
Linux is not going to suddenly ditch it because it doesn't fit the way
you think permissions should work. As others (and you yourself) have
pointed out, there are other mechanisms in Linux to build additional
policy layers above the basic FS semantics. If you care this much
about the issue, write your own filesystem w/ its own enhanced
permissions scheme, but stop asking the Linux development community to
morph its _Unix-like_ operating system into something else and
insisting everyone who doesn't share your subjective point of view is
ignorant.

Dave

Re: what's next for the linux kernel?

[Bodo Eggert]

On Wed, 5 Oct 2005, Marc Perkel wrote:

> What you don't get is that if you don't have rights to write to a file 
> then you shouldn't have the right to delete the file.

In unix, nobody but the kernel has the right to *delete* a file. Therefore 
nobody can delete a file without write permission.

Files are deleted if the last reference is gone. If you play a music file
and unlink it while it's playing, it won't be deleted untill the player
closes the file, since an open filehandle is a reference.


If you like, you can think of it as a kind of instant garbage collection:

Files are the objects referenced by these lists, and if you own 
the object, you can change it. However, as long as there is a reference, 
you can't destroy it, since this would invalidate all references.
Instead, you must remove all references.

Directories are lists of references, and these lists are independent from
the referenced file-objects. If you own the list, you can change it by 
adding or removing files. You can even link files not owned or accessable 
by you:

7eggert@be1:~/tmp > ls -l /tmp/foo/foo
----------    1 7eggert_b users           0 2005-10-05 22:32 /tmp/foo/foo
7eggert@be1:~/tmp > ln /tmp/foo/foo .
7eggert@be1:~/tmp > ls -l
total 0
----------    2 7eggert_b users           0 2005-10-05 22:32 foo
<snip>

Do you notice the link count in the second column?

Let's remove a link:

<snip>
*switch*
7eggert_b@be1:/tmp/foo> rm foo
rm: remove write-protected regular empty file `foo'? y
*switch*
7eggert@be1:~/tmp > ls -l
total 0
----------    1 7eggert_b users           0 2005-10-05 22:32 foo
<snip>

As you can see, each directory-owner can independantly unlink the file.

BTW: The owner can change the permissions on the linked file anytime, so
even if you couldn't link non-accessable files, you could end up with
entries in your private directory you could neither access nor delete.


I can also open the file as 7eggert_b, delete it from another tty and 
still access it's contents:

<snip>
7eggert_b@be1:/tmp/foo> cat > foo
as
*switch*
be1:/home/7eggert/tmp # rm /tmp/foo/foo
be1:/home/7eggert/tmp # ll /proc/4820/fd/1
l-wx------    1 7eggert_b users          64 Oct  5 22:43 /proc/4820/fd/1 
-> /tmp/foo/foo (deleted)
be1:/home/7eggert/tmp # cat /proc/4820/fd/1
as
*switch*
df
be1:/home/7eggert/tmp # cat /proc/4820/fd/1
as
df
<snip>

As you can see, the directory entry is deleted, but the file is still
there. However, making a hard link from a /proc/pid/fd entry is not (yet?)
possible: "ln: creating hard link `baz' to `/proc/4927/fd/1':  Invalid
cross-device link".


-- 
Fun things to slip into your budget
Not in a budget, but in an annual report:
An employee stole 500,000+. They accounted for it on the annual report as
'involountary employee relations expense'

'Undeleting' an open file

[Giuseppe Bilotta]

On Wed, 5 Oct 2005 23:05:34 +0200 (CEST), Bodo Eggert wrote:

> Files are deleted if the last reference is gone. If you play a music file
> and unlink it while it's playing, it won't be deleted untill the player
> closes the file, since an open filehandle is a reference.

BTW, I've always wondered: is there a way to un-unlink such a file?

-- 
Giuseppe "Oblomov" Bilotta

"I weep for our generation" -- Charlie Brown

Re: 'Undeleting' an open file

[Bernd Petrovitsch]

On Fri, 2005-10-07 at 16:14 +0200, Giuseppe Bilotta wrote:
> On Wed, 5 Oct 2005 23:05:34 +0200 (CEST), Bodo Eggert wrote:
> 
> > Files are deleted if the last reference is gone. If you play a music file
> > and unlink it while it's playing, it won't be deleted untill the player
> > closes the file, since an open filehandle is a reference.
> 
> BTW, I've always wondered: is there a way to un-unlink such a file?

Legally not.
You could turn off the power and do a fsck on a not-journalling
filesystem. But even then it is not sure ...

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: 'Undeleting' an open file

[Jose Celestino]

Words by Giuseppe Bilotta [Fri, Oct 07, 2005 at 04:14:27PM +0200]:
> On Wed, 5 Oct 2005 23:05:34 +0200 (CEST), Bodo Eggert wrote:
> 
> > Files are deleted if the last reference is gone. If you play a music file
> > and unlink it while it's playing, it won't be deleted untill the player
> > closes the file, since an open filehandle is a reference.
> 
> BTW, I've always wondered: is there a way to un-unlink such a file?
> 

Well, you can go to /proc/$PID_OF_PROCESSING_OPENING_THE_FILE/fd/

do an ls -la, identify the fd of the file deleted but still open
and do a cp $FD ~/my_deleted_file

Example:

[japc@morgoth:/proc/3743/fd]$ ls -al
total 4
dr-x------  2 japc japc  0 Oct  7 15:25 .
dr-xr-xr-x  4 japc japc  0 Oct  7 15:23 ..
lr-x------  1 japc japc 64 Oct  7 15:25 0 -> /dev/null
l-wx------  1 japc japc 64 Oct  7 15:25 1 -> /home/japc/.xsession-errors
l-wx------  1 japc japc 64 Oct  7 15:25 2 -> /home/japc/.xsession-errors
lr-x------  1 japc japc 64 Oct  7 15:25 255 -> /usr/bin/startkde
[japc@morgoth:/proc/3743/fd]$ cp 255 ~/startkde


-- 
Jose Celestino | http://xpto.org/~japc/files/japc-pgpkey.asc
----------------------------------------------------------------
"Thus the metric system did not really catch on in the States, unless you count
the increasing popularity of the nine-millimeter bullet." -- Dave Barry

Re: 'Undeleting' an open file

[Ian Campbell]

On Fri, 2005-10-07 at 16:14 +0200, Giuseppe Bilotta wrote:
> On Wed, 5 Oct 2005 23:05:34 +0200 (CEST), Bodo Eggert wrote:
> 
> > Files are deleted if the last reference is gone. If you play a music file
> > and unlink it while it's playing, it won't be deleted untill the player
> > closes the file, since an open filehandle is a reference.
> 
> BTW, I've always wondered: is there a way to un-unlink such a file?

Access via /proc/PID/fd/* seems to work:

$ echo "Hello World" > testing
$ exec 10>>testing
$ rm testing
$ ls -l /proc/self/fd/
total 5
lrwx------  1 icampbell icampbell 64 Oct  7 15:28 0 -> /dev/pts/9
lrwx------  1 icampbell icampbell 64 Oct  7 15:28 1 -> /dev/pts/9
l-wx------  1 icampbell icampbell 64 Oct  7 15:28 10
-> /home/icampbell/testing (deleted)
lrwx------  1 icampbell icampbell 64 Oct  7 15:28 2 -> /dev/pts/9
lr-x------  1 icampbell icampbell 64 Oct  7 15:28 3 -> /proc/31390/fd/
$ cat /proc/self/fd/10
Hello World
$

Ian.
-- 
Ian Campbell
Current Noise: Rotting Christ - In Domine Sathana

I may not be totally perfect, but parts of me are excellent.
		-- Ashleigh Brilliant

Re: 'Undeleting' an open file

[Bernd Petrovitsch]

On Fri, 2005-10-07 at 15:30 +0100, Ian Campbell wrote:
> On Fri, 2005-10-07 at 16:14 +0200, Giuseppe Bilotta wrote:
> > On Wed, 5 Oct 2005 23:05:34 +0200 (CEST), Bodo Eggert wrote:
> > 
> > > Files are deleted if the last reference is gone. If you play a music file
> > > and unlink it while it's playing, it won't be deleted untill the player
> > > closes the file, since an open filehandle is a reference.
> > 
> > BTW, I've always wondered: is there a way to un-unlink such a file?
> 
> Access via /proc/PID/fd/* seems to work:
> 
> $ echo "Hello World" > testing
> $ exec 10>>testing
> $ rm testing
> $ ls -l /proc/self/fd/
> total 5
> lrwx------  1 icampbell icampbell 64 Oct  7 15:28 0 -> /dev/pts/9
> lrwx------  1 icampbell icampbell 64 Oct  7 15:28 1 -> /dev/pts/9
> l-wx------  1 icampbell icampbell 64 Oct  7 15:28 10
> -> /home/icampbell/testing (deleted)
> lrwx------  1 icampbell icampbell 64 Oct  7 15:28 2 -> /dev/pts/9
> lr-x------  1 icampbell icampbell 64 Oct  7 15:28 3 -> /proc/31390/fd/
> $ cat /proc/self/fd/10
> Hello World
> $

Did you try linking it?

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: 'Undeleting' an open file

[Andreas Schwab]

Bernd Petrovitsch <bernd@firmix.at> writes:

> On Fri, 2005-10-07 at 15:30 +0100, Ian Campbell wrote:
>> Access via /proc/PID/fd/* seems to work:
>> 
>> $ echo "Hello World" > testing
>> $ exec 10>>testing
>> $ rm testing
>> $ ls -l /proc/self/fd/
>> total 5
>> lrwx------  1 icampbell icampbell 64 Oct  7 15:28 0 -> /dev/pts/9
>> lrwx------  1 icampbell icampbell 64 Oct  7 15:28 1 -> /dev/pts/9
>> l-wx------  1 icampbell icampbell 64 Oct  7 15:28 10
>> -> /home/icampbell/testing (deleted)
>> lrwx------  1 icampbell icampbell 64 Oct  7 15:28 2 -> /dev/pts/9
>> lr-x------  1 icampbell icampbell 64 Oct  7 15:28 3 -> /proc/31390/fd/
>> $ cat /proc/self/fd/10
>> Hello World
>> $
>
> Did you try linking it?

link(2) does not follow symlinks, and there is no flink(2).

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: 'Undeleting' an open file

[Alex Riesen]

On 10/7/05, Bernd Petrovitsch <bernd@firmix.at> wrote:
> > > > Files are deleted if the last reference is gone. If you play a music file
> > > > and unlink it while it's playing, it won't be deleted untill the player
> > > > closes the file, since an open filehandle is a reference.
> > > BTW, I've always wondered: is there a way to un-unlink such a file?
> > Access via /proc/PID/fd/* seems to work:
> Did you try linking it?
>

ln: creating hard link `testfile2' to `/proc/14282/fd/3': Invalid
cross-device link
Pity :)
"cp" works, btw.

Re: 'Undeleting' an open file

[Bernd Petrovitsch]

On Fri, 2005-10-07 at 17:14 +0200, Alex Riesen wrote:
> On 10/7/05, Bernd Petrovitsch <bernd@firmix.at> wrote:
> > > > > Files are deleted if the last reference is gone. If you play a music file
> > > > > and unlink it while it's playing, it won't be deleted untill the player
> > > > > closes the file, since an open filehandle is a reference.
> > > > BTW, I've always wondered: is there a way to un-unlink such a file?
> > > Access via /proc/PID/fd/* seems to work:
> > Did you try linking it?
> >
> 
> ln: creating hard link `testfile2' to `/proc/14282/fd/3': Invalid
> cross-device link
> Pity :)
> "cp" works, btw.

Yup.
<anal>But then it is not un-unlinking and you get another file.</anal>

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: 'Undeleting' an open file

[Miquel van Smoorenburg]

In article <8qo997np4h6n.1ihs13ptrx2y2.dlg@40tude.net>,
Giuseppe Bilotta  <bilotta78@hotpop.com> wrote:
>On Wed, 5 Oct 2005 23:05:34 +0200 (CEST), Bodo Eggert wrote:
>
>> Files are deleted if the last reference is gone. If you play a music file
>> and unlink it while it's playing, it won't be deleted untill the player
>> closes the file, since an open filehandle is a reference.
>
>BTW, I've always wondered: is there a way to un-unlink such a file?

Around 2.4.15 we had the same discussion here - see for example
http://www.ussg.iu.edu/hypermail/linux/kernel/0201.2/0881.html
(but be sure to read the whole thread).

Mike.

Re: 'Undeleting' an open file

[Giuseppe Bilotta]

On Fri, 7 Oct 2005 14:30:37 +0000 (UTC), Miquel van Smoorenburg wrote:

> In article <8qo997np4h6n.1ihs13ptrx2y2.dlg@40tude.net>,
> Giuseppe Bilotta  <bilotta78@hotpop.com> wrote:
>>On Wed, 5 Oct 2005 23:05:34 +0200 (CEST), Bodo Eggert wrote:
>>
>>> Files are deleted if the last reference is gone. If you play a music file
>>> and unlink it while it's playing, it won't be deleted untill the player
>>> closes the file, since an open filehandle is a reference.
>>
>>BTW, I've always wondered: is there a way to un-unlink such a file?
> 
> Around 2.4.15 we had the same discussion here - see for example
> http://www.ussg.iu.edu/hypermail/linux/kernel/0201.2/0881.html
> (but be sure to read the whole thread).

A very interesting read, thank you for the link.

-- 
Giuseppe "Oblomov" Bilotta

Axiom I of the Giuseppe Bilotta
theory of IT:
Anything is better than MS

Re: what's next for the linux kernel?

[Steven Rostedt]

On Wed, 5 Oct 2005, Marc Perkel wrote:
> What you don't get is that if you don't have rights to write to a file
> then you shouldn't have the right to delete the file.  Once you get past
> the "inside the box" Unix thinking you'll see the logic in this. So what
> if the process of deleting a file involves writing to it. That's not
> relevant.

Marc, Get off of it!

In 1987 I first started using Unix. Before that I worked mostly on DOS.
At first the delete w/o ownership shocked me, but then I changed my POV
thinking and found that unlinking from a directory only took write access
to the directory and it made sense to me.  This was all before I began to
"think inside the Unix box".  In fact, it was when I was "thinking inside
the DOS box".

God I was 19 at the time and I easily got a clue. You are stuck on your
own POV and you cant seem to see anything any other way.  So stop trying
to convince us.  We can make up our own minds and already have.

-- Steve

Re: what's next for the linux kernel?

[Bernd Petrovitsch]

On Wed, 2005-10-05 at 07:48 -0700, Marc Perkel wrote:
[...]
> What is incredibly idiotic is a file system that allws you to delete 
> files that you have no write access to. That is stupid beyond belief and 

One that allows you to remove read-only files.

> only the Unix community doesn't get it.

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: what's next for the linux kernel?

[Joe Bob Spamtest]

Marc Perkel wrote:
>> It would be an incredibly idiotic system that auto hides files just
>> because you can't use them.  We have ways to hide files in user space
>> for the convinience of users.  It would be too inconvinient for
>> applications if the OS hid files on us.
>>
>> Len Sorensen
> 
> What is incredibly idiotic is a file system that allws you to delete 
> files that you have no write access to. That is stupid beyond belief and 
> only the Unix community doesn't get it.

A: You're stupid!
B: No, You're stupid!
A: My dad can beat up your dad!
B: No, my dad can beat up yours!
A: My penis is bigger than yours!
B: No, my penis is bigger!
A: (ad infinium)

Look, for those of you who love their beloved netware, go back and use 
it. You don't like the way the unix filesystems work because you don't 
UNDERSTAND how they work. You're talking about a bunch of special-case 
stuff here -- POSIX ACLs and SELinux are your answer. Use them. But for 
christ's sake, STOP BITCHING ABOUT NETWARE.

Re: what's next for the linux kernel?

[linux-os (Dick Johnson)]

On Wed, 5 Oct 2005, Lennart Sorensen wrote:

> On Wed, Oct 05, 2005 at 07:41:21AM -0700, Marc Perkel wrote:
>> If you were going to do it right here's what you would do:
>>
>> People who had files in /tmp would have no rights at all to other users
>> /tmp files.
>> Listing the dirtectory would only display the files you had some access
>> to. If you have no rights you don't even see that the file is there.
>> The effect would be like giving people their own tmp directories.
>
> Except it still wouldn't be able to go: Does file xyz exist?  If not,
> create file xyz.  If someone else had xyz that you didn't see, you would
> still not be able to create it.  So what is the point of NOT showing it
> other than to make it much harder to avoid conflicting names?
>
> if you want to not see files that you have no rights to, filter it in
> your user space application when it matters, and let user space see the
> files when they need to in order to avoid name conflicts.
>
> It would be an incredibly idiotic system that auto hides files just
> because you can't use them.  We have ways to hide files in user space
> for the convinience of users.  It would be too inconvinient for
> applications if the OS hid files on us.
>
> Len Sorensen
> -

Also it has nothing at all to do with the kernel. It's what `ls`
or some other directory-reading program provides for the user.
People often forget that PATH, `pwd`, etc., are just filter
components!

When you `cd` to somewhere, your location hasn't changed at
all!

Without involving the kernel, one can make any kind of filter
to cause any sort of display that you want.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.13 on an i686 machine (5589.55 BogoMips).
Warning : 98.36% of all statistics are fiction.

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: what's next for the linux kernel?

[Lennart Sorensen]

On Wed, Oct 05, 2005 at 10:52:59AM -0400, linux-os (Dick Johnson) wrote:
> Also it has nothing at all to do with the kernel. It's what `ls`
> or some other directory-reading program provides for the user.
> People often forget that PATH, `pwd`, etc., are just filter
> components!
> 
> When you `cd` to somewhere, your location hasn't changed at
> all!

So what does bash do that makes the new location 'busy' when you cd to
it such that you can't unmount it?

> Without involving the kernel, one can make any kind of filter
> to cause any sort of display that you want.

An it certainly is something that should be done in user space.

Len Sorensen

Re: what's next for the linux kernel?

[linux-os (Dick Johnson)]

On Wed, 5 Oct 2005, Lennart Sorensen wrote:

> On Wed, Oct 05, 2005 at 10:52:59AM -0400, linux-os (Dick Johnson) wrote:
>> Also it has nothing at all to do with the kernel. It's what `ls`
>> or some other directory-reading program provides for the user.
>> People often forget that PATH, `pwd`, etc., are just filter
>> components!
>>
>> When you `cd` to somewhere, your location hasn't changed at
>> all!
>
> So what does bash do that makes the new location 'busy' when you cd to
> it such that you can't unmount it?


Well it doesn't make a file-system location busy! It's only files
that are open-for-write that prevent a file-system from being un-mounted!

You can properly shut down a system with the following commands from
a dumb terminal (ctrl-ALT F1,F2, etc).

kill -TERM -1	# Kill everybody but me and 'init'
sleep 1		# Wait a bit
kill -9 -1	# Really kick the hangers-on
sleep 1		# Wait again
umount -a	# Umount all file systems

After you execute `umount -a`, you can still read the file-system
because `umount` only made it R/O.

`>foo`
shows that the file-system is R/O, you can hit the reset or power
switch now.

Certain distros create a file in the top directory that is supposed
to tell startup that the system was not properly shut down, "/.autofsck",
if you deleted that before the above sequence, the machine can
be restarted with no informational error messages about the shutdown.

`cd` executes function-code 12 which makes all opens() start from the
input string "path" if it doesn't have a full path. It's just a filter.
Same for opendir() if a directory listing is to be obtained.

>
>> Without involving the kernel, one can make any kind of filter
>> to cause any sort of display that you want.
>
> An it certainly is something that should be done in user space.
>

Could be done from user-space but opening an ordinary file
would require that the full path be obtained from somewhere
because the kernel wouldn't "know" where to create it if the
full path wasn't part of the open. `cd` is a kernel-call that
conveniently stores the part of the path-name that you don't
want to have to repeat for every open.

> Len Sorensen
>

Cheers,
Dick Johnson
Penguin : Linux version 2.6.13 on an i686 machine (5589.55 BogoMips).
Warning : 98.36% of all statistics are fiction.

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: what's next for the linux kernel?

[Luke Kenneth Casson Leighton]

On Wed, Oct 05, 2005 at 07:41:21AM -0700, Marc Perkel wrote:
> If you were going to do it right here's what you would do:
> 
> People who had files in /tmp would have no rights at all to other users 
> /tmp files.
> Listing the dirtectory would only display the files you had some access 
> to. If you have no rights you don't even see that the file is there.
> The effect would be like giving people their own tmp directories.
 
  ahh, *sigh*, i remember the days.

  in 1989 i looked in /tmp on our sunos 4.1.3 server at
  imperial, which was running a bit slow, went "eek, that's
  a lot of files in /tmp" and did am rm -fr /tmp.

  a few minutes later the sysadmins quite literally stormed in.

  apparently the printer queue temp files were stored in /tmp and 100
  third year students were all trying to print out their course-work,
  last minute.

  oops.

  yes, imperial college third year theory of computing students of
  1987-1990, it was me.

  l.

Re: what's next for the linux kernel?

[Lennart Sorensen]

On Wed, Oct 05, 2005 at 04:24:47PM +0100, Luke Kenneth Casson Leighton wrote:
>   ahh, *sigh*, i remember the days.
> 
>   in 1989 i looked in /tmp on our sunos 4.1.3 server at
>   imperial, which was running a bit slow, went "eek, that's
>   a lot of files in /tmp" and did am rm -fr /tmp.

Why would /tmp allow you to delete files there you didn't own unless you
were root?  Why would someone with root blindly delete things they
didn't know what were?

>   a few minutes later the sysadmins quite literally stormed in.

And promptly removed root access from the person that wasn't qualified
to have it in the first place? :)

>   apparently the printer queue temp files were stored in /tmp and 100
>   third year students were all trying to print out their course-work,
>   last minute.
> 
And why would the printer queue use /tmp in the first place?

>   oops.
> 
>   yes, imperial college third year theory of computing students of
>   1987-1990, it was me.

Did they ever let you have root again?

Len Sorensen

Re: what's next for the linux kernel?

[Luke Kenneth Casson Leighton]

On Wed, Oct 05, 2005 at 11:30:06AM -0400, Lennart Sorensen wrote:
> On Wed, Oct 05, 2005 at 04:24:47PM +0100, Luke Kenneth Casson Leighton wrote:
> >   ahh, *sigh*, i remember the days.
> > 
> >   in 1989 i looked in /tmp on our sunos 4.1.3 server at
> >   imperial, which was running a bit slow, went "eek, that's
> >   a lot of files in /tmp" and did am rm -fr /tmp.
> 
> Why would /tmp allow you to delete files there you didn't own unless you
> were root?  

 i have no idea.  as a user, i just did rm -fr /tmp/* (sorry - not
 rm -fr /tmp) and it worked.

 as a user.

 not root.

> >   a few minutes later the sysadmins quite literally stormed in.
> 
> And promptly removed root access from the person that wasn't qualified
> to have it in the first place? :)
 
 they weren't dumb enough to give it to me.

> >   apparently the printer queue temp files were stored in /tmp and 100
> >   third year students were all trying to print out their course-work,
> >   last minute.
> > 
> And why would the printer queue use /tmp in the first place?
 
 ahh, that would answer the implicit question as to why they
 jumped up and down at me rather than frog-marched me off campus.

> >   oops.
> > 
> >   yes, imperial college third year theory of computing students of
> >   1987-1990, it was me.
> 
> Did they ever let you have root again?

 i was a student there.  they didn't let _anyone_ like me have root.
 
 someone got into trouble for even demonstrating a security
 vulnerability.

 l.

Re: what's next for the linux kernel?

[Lennart Sorensen]

On Wed, Oct 05, 2005 at 04:42:26PM +0100, Luke Kenneth Casson Leighton wrote:
>  i have no idea.  as a user, i just did rm -fr /tmp/* (sorry - not
>  rm -fr /tmp) and it worked.
> 
>  as a user.
> 
>  not root.

Then some admin didn't qualify for root having apparently removed the t
bit from /tmp making it a world writeable dir.  Ouch.

>  they weren't dumb enough to give it to me.

But they made /tmp world writeable it seems.  Impresive. :)

>  ahh, that would answer the implicit question as to why they
>  jumped up and down at me rather than frog-marched me off campus.

Yep.  What you did should have been prevented by the system.  So the
system was misconfigured.

>  i was a student there.  they didn't let _anyone_ like me have root.
>  
>  someone got into trouble for even demonstrating a security
>  vulnerability.

Well this one sounds more liek a major misconfiguration than a security
problem.  Well allowing people to mess with temp could be seen as a
security problem but only until the permissions were fixed back to what
they would have originally been when the system was installed.

Len Sorensen

Re: what's next for the linux kernel?

[Ragnar Hojland Espinosa]

On Wed, Oct 05, 2005 at 11:55:16AM -0400, Lennart Sorensen wrote:
> On Wed, Oct 05, 2005 at 04:42:26PM +0100, Luke Kenneth Casson Leighton wrote:
> >  i have no idea.  as a user, i just did rm -fr /tmp/* (sorry - not
> >  rm -fr /tmp) and it worked.
> > 
> >  as a user.
> > 
> >  not root.
> 
> Then some admin didn't qualify for root having apparently removed the t
> bit from /tmp making it a world writeable dir.  Ouch.
> 
> >  they weren't dumb enough to give it to me.
> 
> But they made /tmp world writeable it seems.  Impresive. :)

Silly accidents like that happen.  A lazy tarballer in action:

# ls -ld foo
drwxr-xr-x  2 root   root  48 Oct  6 17:34 foo
# cd foo
# tar cf ../foo.tar .

And too sleepy root who blindly untars to /tmp

# ls -ld tmp
drwxrwxrwt  2 root   root  48 Oct  6 17:34 tmp
# tar xf foo.tar
# ls -ld tmp
drwxr-xr-x  2 root   root     72 Oct  6 17:36 tmp

woops.

-- 
Ragnar Hojland - Project Manager
Linalco "Specialists in Linux and Free Software"
http://www.linalco.com  Tel: +34-91-4561700

Re: what's next for the linux kernel?

[David Leimbach]

On 10/5/05, Nix <nix@esperi.org.uk> wrote:
> On 4 Oct 2005, Bodo Eggert stated:
> > BTW: YANI: That about a tmpfs where all-numerical entries can only be
> > created by the corresponding UID? This would provide a secure, private
> > tmp directory to each user without the possibility of races and denial-of-
> > service attacks. Maybe it should be controlled by a mount flag.
>
> Wouldn't it be less kludgy to just use the existing private namespace
> stuff to provide each user with its own /tmp? (Or each user's session,
> rather, which is probably much easier, as that corresponds precisely to
> one process tree).
>

It would if the rest of the system really enforced this "privacy".  In
plan 9 /tmp is really a bind to /usr/$user/tmp.  And if you launch
something like "ramfs" [a userland 9P server] it binds a ram disk
device over /tmp by default unless you tell it otherwise, then you
have a ram-backed directory only for the current process and its
children in /tmp.  This is useful for pulling things out of the
encrypted storage like factotum keys [sort of like a keyring for all
factotum based authentication including 9P mounts and even ssh
connections that use no ssh-keys].  When your process goes away so
does the decrypted keyfile, pretty nice.

Back on topic...

The problem with private namespaces on Linux is that they really
aren't so much.  mount will update /etc/mtab for all to see and even
/proc/<pid>/mounts is world readable [though it doesn't give useful
bind information anyway on linux... just the disk device it appears].

On one hand you've got very specific information in mtab about all the
binding that's been done and on the other hand you've got not so
useful information on a per-process basis in /proc.

I think private namespaces could actually be made more-so but the rest
of the system has to cooperate and I doubt that I have the energy to
do the evangelism and requisite proofs of concept for Linux.  It's far
easier for me to just use Plan 9 and Inferno instead of trying to
assimilate Linux, even though I think I'd prefer Linux if it were more
like the former two.

Maybe it's time for another BSD fork? [*runs away from the disapproval*]

Dave

Re: what's next for the linux kernel?

[Bodo Eggert]

On Wed, 5 Oct 2005, David Leimbach wrote:

[snip quotes]

> It would if the rest of the system really enforced this "privacy".  In
> plan 9 /tmp is really a bind to /usr/$user/tmp.  And if you launch
> something like "ramfs" [a userland 9P server] it binds a ram disk
> device over /tmp by default unless you tell it otherwise, then you
> have a ram-backed directory only for the current process and its
> children in /tmp.
[...]

> This is useful for pulling things out of the
> encrypted storage like factotum keys [sort of like a keyring for all
> factotum based authentication including 9P mounts and even ssh
> connections that use no ssh-keys].  When your process goes away so
> does the decrypted keyfile, pretty nice.

You'd usurally just create+open a file and erase it without closing it.
The only access to this file is by using the file descriptor (or, off 
cause, /proc/pid/fd/num). If the last reference to this file, the running 
process, is gone, so is the file.

> Back on topic...
> 
> The problem with private namespaces on Linux is that they really
> aren't so much.  mount will update /etc/mtab for all to see and even

Userspace problem.-)

> /proc/<pid>/mounts is world readable [though it doesn't give useful
> bind information anyway on linux... just the disk device it appears].

There was some proc privacy patch some time ago. It was argued about 
because some sites want peer review on system usage. I lost track 
if it was included.

> I think private namespaces could actually be made more-so but the rest
> of the system has to cooperate and I doubt that I have the energy to
> do the evangelism and requisite proofs of concept for Linux.  It's far
> easier for me to just use Plan 9 and Inferno instead of trying to
> assimilate Linux, even though I think I'd prefer Linux if it were more
> like the former two.

The plan is:

1) make namespaces joinable
2) ???
3) profit

No, that's wrong. The plan is (should be?):

1) make namespaces joinable in a sane way
2) wait for the shared subtree patch
3) make pam join the per-user-namespace
4) make pam automount tmpfs on the private /tmp

-- 
Top 100 things you don't want the sysadmin to say:
44. System coming down in 0 min....

Re: what's next for the linux kernel?

[David Leimbach]

ss, is gone, so is the file.
>
> > Back on topic...
> >
> > The problem with private namespaces on Linux is that they really
> > aren't so much.  mount will update /etc/mtab for all to see and even
>
> Userspace problem.-)

Sure is, which is why I think it's easier to fork a BSD to make it do
what someone wants than to roll my own linux distribution :-).  
Perhaps that's a problem of perception and not a really good
measurement of the amount of energy involved in either alternative.

Sometimes it sure seems easier to keep the userspace stuff with the kernel.

> > I think private namespaces could actually be made more-so but the rest
> > of the system has to cooperate and I doubt that I have the energy to
> > do the evangelism and requisite proofs of concept for Linux.  It's far
> > easier for me to just use Plan 9 and Inferno instead of trying to
> > assimilate Linux, even though I think I'd prefer Linux if it were more
> > like the former two.
>
> The plan is:
>
> 1) make namespaces joinable
> 2) ???
> 3) profit
>
> No, that's wrong. The plan is (should be?):
>
> 1) make namespaces joinable in a sane way
> 2) wait for the shared subtree patch
> 3) make pam join the per-user-namespace
> 4) make pam automount tmpfs on the private /tmp

I'm not sure what you mean by a joinable namespace.  I also am not
sure I want them :-).

I think of namespaces as being fundamental to the process model and
that they are inherited from the parent and new ones are created in a
sort of COW fashion [or at least have similar behavior].

You might want a session namespace instead of a joinable per-process
namespace but I think that might be a slightly different point of
view.

Dave

Re: what's next for the linux kernel?

[Nix]

On Wed, 5 Oct 2005, David Leimbach said:
>> 1) make namespaces joinable in a sane way
>> 2) wait for the shared subtree patch
>> 3) make pam join the per-user-namespace
>> 4) make pam automount tmpfs on the private /tmp
> 
> I'm not sure what you mean by a joinable namespace.  I also am not
> sure I want them :-).

They are namespaces which processes can join. Right now you can do
it by chrooting into /proc/{pid}/root, but this is, as Bodo said,
not a very sane API.

Without this, a user starting two sessions gets two namespaces,
which is profoundly counterintuitive from the user's POV.

> I think of namespaces as being fundamental to the process model and
> that they are inherited from the parent and new ones are created in a
> sort of COW fashion [or at least have similar behavior].

Yes, but you can change them too (that's what e.g. mount() is for!)

> You might want a session namespace instead of a joinable per-process
> namespace but I think that might be a slightly different point of
> view.

I think that's the idea; a filesystem holding namespaces that you're
allowed to chroot() into.

-- 
`Next: FEMA neglects to take into account the possibility of
fire in Old Balsawood Town (currently in its fifth year of drought
and home of the General Grant Home for Compulsive Arsonists).'
            --- James Nicoll

Re: what's next for the linux kernel?

[Luke Kenneth Casson Leighton]

> > 1) make namespaces joinable in a sane way
> > 2) wait for the shared subtree patch
> > 3) make pam join the per-user-namespace
> > 4) make pam automount tmpfs on the private /tmp
 
 per-user namespaces on /tmp would solve a lot of the problems faced by
 selinux with respect to directory permissions on /tmp/.font-unix
 and /tmp/.X11-unix.
 
 there are a lot of legacy apps that no-one wants to modify to get them
 to create/read /tmp/x-windows/.X11-unix.

 oops.

Re: what's next for the linux kernel?

[grundig]

El Thu, 6 Oct 2005 00:23:30 +0100,
Luke Kenneth Casson Leighton <lkcl@lkcl.net> escribió:

>  there are a lot of legacy apps that no-one wants to modify to get them
>  to create/read /tmp/x-windows/.X11-unix.

What's the point of caring about security for a legacy app if nobody 
is going to fix it if a security problema arises?


http://packages.debian.org/unstable/admin/libpam-tmpdir 

is good enought IMO

Re: what's next for the linux kernel?

[Tomasz Kłoczko]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1074 bytes --]

On Thu, 6 Oct 2005 grundig@teleline.es wrote:

> El Thu, 6 Oct 2005 00:23:30 +0100,
> Luke Kenneth Casson Leighton <lkcl@lkcl.net> escribió:
>
>>  there are a lot of legacy apps that no-one wants to modify to get them
>>  to create/read /tmp/x-windows/.X11-unix.
>
> What's the point of caring about security for a legacy app if nobody
> is going to fix it if a security problema arises?
>
>
> http://packages.debian.org/unstable/admin/libpam-tmpdir
>
> is good enought IMO

BTW. Also it will be good say something about storing unix sockets by 
system programs (/tmp/x-windows/.X11-unix which is owned by root.root) in 
/tmp.

http://www.pathname.com/fhs/pub/fhs-2.3.html#REQUIREMENTS14
says about /var/run:
"System programs that maintain transient UNIX-domain sockets must place 
them in this directory."

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@rudy.mif.pg.gda.pl*

Re: what's next for the linux kernel?

[Greg Norris]

On Thu, Oct 06, 2005 at 11:53:39AM +0200, grundig@teleline.es wrote:
> What's the point of caring about security for a legacy app if nobody 
> is going to fix it if a security problema arises?
> 
> 
> http://packages.debian.org/unstable/admin/libpam-tmpdir 
> 
> is good enought IMO

That reminds me, gdm hangs (on Debian sid, anyway) when using the 
pam_tmpdir.so module.  I was meaning to file a bugreport... guess I'd 
better get moving.

Re: what's next for the linux kernel?

[Marc Perkel]

Bodo Eggert wrote:

>Marc Perkel <marc@perkel.com> wrote:
>
>[...]
>  
>
>>I'll run through a few ideas here.
>>    
>>
>
>  
>
>>Novell Netware type permissions. ACLs are a step in the right direction
>>but Linux isn't any where near where Novell was back in 1990. Linux lets
>>you - for example - to delete files that you have no read or write
>>access rights to.
>>    
>>
>
>It lets you unlink them. That's different from deleting, since the owner
>may have his/her private link to that file.
>
>Unlinking is changing the contents of a directory, and it's controlled by
>the write permission of the containing directory.
>
>  
>
There would be different rights to eack link.

>>Netware on the other hand prevents you from deleting
>>files that you can't write to and if you have no right it is as if the
>>file isn't there.
>>    
>>
>
>Imagine a /tmp directory (writable by world) with user "a" creating a file
>"foo", umask=077 and user "b" trying to do the same. User "b" will get
>'file exists' if he tries to create it, and 'file does not exist' if he
>tries to list it. He will go nuts.
>  
>
Users should have private temp directory space. Two user trying to 
create the same file in the same directory isn't going to work under any 
operating system.

>BTW: YANI: That about a tmpfs where all-numerical entries can only be
>created by the corresponding UID? This would provide a secure, private
>tmp directory to each user without the possibility of races and denial-of-
>service attacks. Maybe it should be controlled by a mount flag.
>
>  
>
>>You can't even see it in the directory. Netware also
>>has inherited permissions like Windows and Samba has and this is doing
>>it right.
>>    
>>
>
>You can't do that if you have hardlinks. However, I missed the feature of
>overruling file permissions in some special directories, e.g. anything
>put under /pub should ignore umask and be a+rX.
>  
>
You have to realize the Netware does things differently and that Linux 
limitations don't apply to Netware.

>  
>
>>File systems and individual directories should be able to be
>>flagged as casesensitive/insensitive.
>>    
>>
>
>IMHO not needed.
>  
>
But just because you don't need it doesn't mean other people don't. If 
you are running Samba pretending to be a case insensitive file system 
then this is a good feature.

Re: what's next for the linux kernel?

[Julian Blake Kongslie]

[-- Attachment #1: Type: text/plain, Size: 858 bytes --]

On Wed, 05 Oct 2005 13:27:15 -0700
Marc Perkel <marc@perkel.com> wrote:
> There would be different rights to eack link.

Well, color me confused.

You appear to be saying that the permission on a file differ depending
on which link you are accessing it by. Furthermore, your stance seems to
imply that linking to a file grants either write permission or ownership
on the new link.

So, under this permission model, I could link to /etc/passwd in my
home directory, edit the link to change my UID to zero, then relogin to
the system as an administrator.

Not that I would need to, of course, because any user who owns/could
write to a directory would be able to alter any file on the entire
system. I know they're called "permission" models, but that seems
*extremely* permissive...

-- 
-Julian Blake Kongslie
<jblake@omgwallhack.org>

[-- Attachment #2: Type: application/pgp-signature, Size: 287 bytes --]

Re: what's next for the linux kernel?

[Bas Westerbaan]

You can delete a directory entry to a file if you have proper
permission to the directory.

You cannot read or write the file if the file doesn't give you permission to.

A hard link makes an additional directory entry to a certain file. You
delete the directory entry to the file, not the file.

And permissions are the same for all instances of the file.

My 2 cents.

On 10/5/05, Julian Blake Kongslie <jblake@omgwallhack.org> wrote:
> On Wed, 05 Oct 2005 13:27:15 -0700
> Marc Perkel <marc@perkel.com> wrote:
> > There would be different rights to eack link.
>
> Well, color me confused.
>
> You appear to be saying that the permission on a file differ depending
> on which link you are accessing it by. Furthermore, your stance seems to
> imply that linking to a file grants either write permission or ownership
> on the new link.
>
> So, under this permission model, I could link to /etc/passwd in my
> home directory, edit the link to change my UID to zero, then relogin to
> the system as an administrator.
>
> Not that I would need to, of course, because any user who owns/could
> write to a directory would be able to alter any file on the entire
> system. I know they're called "permission" models, but that seems
> *extremely* permissive...
>
> --
> -Julian Blake Kongslie
> <jblake@omgwallhack.org>
>
>
>



--
Bas Westerbaan
http://blog.w-nz.com/
GPG Public Keys: http://w-nz.com/keys/bas.westerbaan.asc

Re: what's next for the linux kernel?

[Julian Blake Kongslie]

[-- Attachment #1: Type: text/plain, Size: 760 bytes --]

On Wed, 5 Oct 2005 22:51:32 +0200
Bas Westerbaan <bas.westerbaan@gmail.com> wrote:

> You can delete a directory entry to a file if you have proper
> permission to the directory.
> 
> You cannot read or write the file if the file doesn't give you
permission to.
> 
> A hard link makes an additional directory entry to a certain file. You
> delete the directory entry to the file, not the file.
> 
> And permissions are the same for all instances of the file.
> 
> My 2 cents.

That is the UNIX model, yes. And I think it makes perfect sense. And as
a side effect, we can delete links to files which we do not own, and
cannot write to.

Does NetWare have an equivalent of hardlinks?

-- 
-Julian Blake Kongslie
<jblake@omgwallhack.org>

[-- Attachment #2: Type: application/pgp-signature, Size: 287 bytes --]

Re: what's next for the linux kernel?

[Bodo Eggert]

Nix <nix@esperi.org.uk> wrote:
> On 4 Oct 2005, Marc Perkel announced authoritatively:

>>             Netware also has inherited permissions like Windows and
>> Samba has and this is doing it right.
> 
> s/right/wrong/
> 
> Look at a NetWare permission on some file and you can't tell what the
> effective permission is, because it depends on inherited ones as well.
> Look at an effective permission and you can't tell which parts of it
> will change if you change the inherited permission.

MS solved that part by not allowing partially defined permissions.
(At least AFAI can tell from the UI.)

> Unix has inherited permissions in one sense: you can't get at a file
> via some path if one of the directories in that path is unreadable.

NACK. ITYM non-accessable (-x), and it's only true if you can't reach it or
one of the other links from $PWD and the directories you can fchdir to
(which, admittedly, is the usural case).

> Even *that* causes regular problems,

ACK.-)

>>                                       File systems and individual
>> directories should be able to be flagged as casesensitive/insensitive.
> 
> Only if you're willing to change POSIX to include a call to check filenames
> for identity,

You'd "just" need a way to determine the canonialized form. Still an evil
masterplan.

[...]
> It would also require case-conversion and locale-handling code, probably
> including UTF-8 canoncalization code, inside the kernel. This would
> greatly increase kernel complexity for a very small reward, and lead to
> Al Viro's early death from cerebral aneurysm combined with involuntary
> projectile vomiting. This cannot be considered a good thing.

a) NLS is in the kernel, and if utf-8 filenames are supposed to be used,
   an utf-8 checker rejecting non-canonialized strings will be desirable
   to avoid binary trash in filenames or lookalike filenames. The
   conversion to the canonialized form should happen outside the kernel.

   (I know POSIX doesn't define a propper return value, but the return
    value used for VFAT works and it's better than dealing with
    $'M\x{0430}kefile' looking like Makefile)

b) ACK, I don't think caseless handling of filenames is a good thing,
   it would needlessly bloat the kernel by opening a can of worms.
   E.g. 'ß' would be converted to 'SS'[0] in German or 'B' in greek.


[0] or, if you like and bend the standard, to 'SZ' if the word with 'SS'
    would clash with another word.

> Now /etc/mtab, *that* is an abomination, and a small kernel improvement
> (allowing arbitrary flag strings to be passed by mount into the kernel
> solely for display in the appropriate /proc/mounts field) could
> eliminate it and replace it entirely with /proc/mounts.

What about making all fs ignore the
-omount="$tool:foo:bar;$tool2=baz:barf..." parameter?

This is a cruel hack, but it will be backward compatible.
(If your hammer is big enough, the problem may turn out to be a nail.)

-- 
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
verbreiteten Lügen zu sabotieren.

Re: what's next for the linux kernel?

[Nix]

On Wed, 05 Oct 2005, Bodo Eggert suggested tentatively:
> Nix <nix@esperi.org.uk> wrote:
>> On 4 Oct 2005, Marc Perkel announced authoritatively:
> 
>> Look at a NetWare permission on some file and you can't tell what the
>> effective permission is, because it depends on inherited ones as well.
>> Look at an effective permission and you can't tell which parts of it
>> will change if you change the inherited permission.
> 
> MS solved that part by not allowing partially defined permissions.
> (At least AFAI can tell from the UI.)

The UI lies grossly, but in this area I think you are right. (I'm still
unclear as to what happens to permissions when you copy something:
do the inherited parts change, or not?)

>> Unix has inherited permissions in one sense: you can't get at a file
>> via some path if one of the directories in that path is unreadable.
> 
> NACK. ITYM non-accessable (-x), and it's only true if you can't reach it or
> one of the other links from $PWD and the directories you can fchdir to
> (which, admittedly, is the usural case).

Yeah, I was being sloppy. You got what I meant. (In similar wise, file
permissions don't stop you from reading a file if you can coerce someone
else into opening it and passing you its fd. Nonetheless, file
permissions almost always *do* work.)

>>>                                       File systems and individual
>>> directories should be able to be flagged as casesensitive/insensitive.
>> 
>> Only if you're willing to change POSIX to include a call to check filenames
>> for identity,
> 
> You'd "just" need a way to determine the canonialized form. Still an evil
> masterplan.

It'd still require changing POSIX and rewriting a large part of the
universe.

> [...]
>> It would also require case-conversion and locale-handling code, probably
>> including UTF-8 canoncalization code, inside the kernel. This would
>> greatly increase kernel complexity for a very small reward, and lead to
>> Al Viro's early death from cerebral aneurysm combined with involuntary
>> projectile vomiting. This cannot be considered a good thing.
> 
> a) NLS is in the kernel,

I don't think enough of it to do this is in there, at least not if you
aren't using something like NTFS.

>                          and if utf-8 filenames are supposed to be used,
>    an utf-8 checker rejecting non-canonialized strings will be desirable
>    to avoid binary trash in filenames or lookalike filenames. The
>    conversion to the canonialized form should happen outside the kernel.

Yes. But where? libc? (I can just see Ulrich going for *this*!)

> b) ACK, I don't think caseless handling of filenames is a good thing,
>    it would needlessly bloat the kernel by opening a can of worms.
>    E.g. 'ß' would be converted to 'SS'[0] in German or 'B' in greek.

... which means that either you lose per-process locale-dependence
via LANG et all, or you get the possibility of directories containing
several files with the same name from some users' POV.

Neither seems good to me; even though we already have part of this with
NTFS, we should not inflict it on people needlessly.

>> Now /etc/mtab, *that* is an abomination, and a small kernel improvement
>> (allowing arbitrary flag strings to be passed by mount into the kernel
>> solely for display in the appropriate /proc/mounts field) could
>> eliminate it and replace it entirely with /proc/mounts.
> 
> What about making all fs ignore the
> -omount="$tool:foo:bar;$tool2=baz:barf..." parameter?

Well, they'd have to dump it into /proc/mounts, too (I guess that would
happen magically). That would unbreak the few things this cares about.

> This is a cruel hack, but it will be backward compatible.
> (If your hammer is big enough, the problem may turn out to be a nail.)

Indeed. I'm fairly sure this problem is trivially solvable: it's far
easier than the *other* problems lying in wait down the per-user-
namespace path. :)

-- 
`Next: FEMA neglects to take into account the possibility of
fire in Old Balsawood Town (currently in its fifth year of drought
and home of the General Grant Home for Compulsive Arsonists).'
            --- James Nicoll

Re: what's next for the linux kernel?

[Bodo Eggert]

On Wed, 5 Oct 2005, Nix wrote:
> On Wed, 05 Oct 2005, Bodo Eggert suggested tentatively:

[...]
> >                          and if utf-8 filenames are supposed to be used,
> >    an utf-8 checker rejecting non-canonialized strings will be desirable
> >    to avoid binary trash in filenames or lookalike filenames. The
> >    conversion to the canonialized form should happen outside the kernel.
> 
> Yes. But where? libc? (I can just see Ulrich going for *this*!)

Either there or in a seperate library.

> > b) ACK, I don't think caseless handling of filenames is a good thing,
> >    it would needlessly bloat the kernel by opening a can of worms.
> >    E.g. 'ß' would be converted to 'SS'[0] in German or 'B' in greek.
> 
> ... which means that either you lose per-process locale-dependence
> via LANG et all, or you get the possibility of directories containing
> several files with the same name from some users' POV.
> 
> Neither seems good to me; even though we already have part of this with
> NTFS, we should not inflict it on people needlessly.

ACK, that's my point.

-- 
Field experience is something you don't get until just after you need it.