[Cc trimmed - let's spare CODA list, they did nothing to deserve YABFFH]
On Fri, 3 Dec 1999, Brandon S. Allbery KF8NH wrote:
[UNIX 101 for Andrea - take 2]
Gentlemen, let's _stop_ it. About the only non-obvious thing said during
the whole thread was the claim that revoke() will take ~20 lines.
On Fri, 3 Dec 1999, Alexander Viro wrote:
>patches I've seen were 2 orders of magnitude larger. Andrea, could you
>share the method to do it?
IIRC if you'll check the l-k archive around May 1999 you'll find the patch
I am talking about.
Andrea
Jan Harkes <[EMAIL PROTECTED]> writes:
> On Fri, Dec 03, 1999 at 12:18:19PM -0500, Alexander Viro wrote:
> > On Fri, 3 Dec 1999, Andrea Arcangeli wrote:
> >
> > > I don't like having only coda breaking the semantic. You'll end getting
> > > reports of "program X doesn't work with coda, why?". If
In message <[EMAIL PROTECTED]>, Andrea
Arcang
eli writes:
+-
| On Fri, 3 Dec 1999, Alexander Viro wrote:
| >Oh, great. So your reasons should pass for arbitrary filesystem, right?
|
| It's always been so. Sorry if I am been not clear. I was talking about the
| VFS not about lowlevel fs. I do
On Fri, 3 Dec 1999, Alexander Viro wrote:
>The last time: your change does not increase security. Sigh... Andrea,
You say again for the open(2) issue? As I just said the open(2) is
possible only due the lazyness of not having implemented revoke(2) yet.
Just because fixing hardlinks is not enoug
Richard Gooch writes the following:
>
>Andrea Arcangeli writes:
>> On Fri, 3 Dec 1999, Richard Gooch wrote:
>>
>> >as well as very very hostile environments.
>>
>> It doesn't work at all on environments where if there's an exploited
>> "quota exceeded" is a major problem.
>
>Of course it still w
In message <[EMAIL PROTECTED]>, Andrea
Arcang
eli writes:
+-
| then. It's a namespace issue. If I put my inode in my directory it must
| not finish into /tmp after some time by somebody that has nothing to do
| with me.
+--->8
*bzzzt*
"Namespace issue"? Perhaps you should learn some Unix b
On Fri, 3 Dec 1999, Alexander Viro wrote:
>No, Andrea. There are _other_ good reasons for that. E.g. lusers being
>able to fill the root filesystem - _not_ a thing you really want.
Of course I am assuming you want to use ext2 or another fs that reserve to
root a percentage of free space.
Andre
On Fri, 3 Dec 1999, Richard Gooch wrote:
>No, the reason for having /tmp on a separate FS is so that damage to
>/tmp (which you don't care about) can't affect /. The more you write
>to a FS, the more chance you have of damaging it, even parts that you
>don't write to.
Of course if you put /tmp i
On Fri, 3 Dec 1999, Richard Gooch wrote:
>why) and that would adversely impact other users. You're proposing
>something for your (perceived) convenience, at the expense of others.
As _just_ said I don't need it for myself.
>think *very hard* if you really need to do what you want to do.
Incide
Andrea Arcangeli writes:
> On Fri, 3 Dec 1999, Richard Gooch wrote:
>
> >as well as very very hostile environments.
>
> It doesn't work at all on environments where if there's an exploited
> "quota exceeded" is a major problem.
Of course it still works! If you lock up your directories, people
c
On Fri, 3 Dec 1999, Andrea Arcangeli wrote:
> On Fri, 3 Dec 1999, Alexander Viro wrote:
>
> >... and F- on UNIX SA 101 - if you don't know the reasons to keep /tmp on
> >a separate filesystem.
>
> Would you call this a solution? This is a very ugly workaround. The fact
> this works is only a
On Fri, 3 Dec 1999, Andrea Arcangeli wrote:
> On Fri, 3 Dec 1999, Alexander Viro wrote:
>
> >Oh, great. So your reasons should pass for arbitrary filesystem, right?
>
> It's always been so. Sorry if I am been not clear. I was talking about the
> VFS not about lowlevel fs. I don't either know
On Fri, 3 Dec 1999, Richard Gooch wrote:
>as well as very very hostile environments.
It doesn't work at all on environments where if there's an exploited
"quota exceeded" is a major problem.
The hardlink is not the only way to exploit quota but that's not a good
point to not fix the hardlink th
Andrea Arcangeli writes:
> On Fri, 3 Dec 1999, Alexander Viro wrote:
>
> >Andrea, WHAT FOR? Give a rationale for your change, other than "let's
> >change it". Name a single benefit of proposed semantics.
>
> The rational is that I don't want to see my inodes sparse around the
> fs by an luser. I
On Fri, 3 Dec 1999, Richard Gooch wrote:
>Firstly, /tmp should be a separate partition anyway. Systems with /tmp
>on the same FS as / (along with everything else :-() are
>mis-configured.
I disagree. It's mis-configured because right now you are using
side-effects of hard limitations as features
Andrea Arcangeli writes:
> On Fri, 3 Dec 1999, Alexander Viro wrote:
>
> >... and F- on UNIX SA 101 - if you don't know the reasons to keep /tmp on
> >a separate filesystem.
>
> Would you call this a solution? This is a very ugly workaround. The
> fact this works is only a side effect of the li
Andrea Arcangeli writes:
> On Fri, 3 Dec 1999, Richard Gooch wrote:
>
> >Firstly, /tmp should be a separate partition anyway. Systems with /tmp
> >on the same FS as / (along with everything else :-() are
> >mis-configured.
>
> I disagree. It's mis-configured because right now you are using
> sid
On Fri, 3 Dec 1999, Alexander Viro wrote:
>Oh, great. So your reasons should pass for arbitrary filesystem, right?
It's always been so. Sorry if I am been not clear. I was talking about the
VFS not about lowlevel fs. I don't either know why coda especially
dislikes hardlinks.
>Let's see: you a
Like it or not, Unix link() semantics have allowed links to unwritable files
from the very beginning. There is no telling what you might break if you
changed it; historically, spooling systems of various sorts have used such
links for locking and queue manipulation. And as others have pointed ou
Alexander Viro writes:
>
>
> On Fri, 3 Dec 1999, Andrea Arcangeli wrote:
>
> > I don't need quota for myself either. So? Do you suggest to remove quota
> > from the kernel because me and you don't need it? You can't just take
> > decisions for everybody only looking at your needs. Or you should
On Fri, 3 Dec 1999, Andrea Arcangeli wrote:
> Really it seems nobody cares about the implications of the problem and if
> nobody needs the change I don't need it either for myself. So probably
> it's better to put the change in an unofficial patch (for example in the
> Solar's secure-linux patch
Andrea Arcangeli writes:
> On Fri, 3 Dec 1999, Richard Gooch wrote:
>
> >And I want the opposite: I want any user to be able to make hard links
> >to my files, without needing write access to the inodes, and without
> >needing some stupid set{u|g}id binary.
>
> Any sane workgroup project uses an
On Fri, 3 Dec 1999, Andrea Arcangeli wrote:
> I don't need quota for myself either. So? Do you suggest to remove quota
> from the kernel because me and you don't need it? You can't just take
> decisions for everybody only looking at your needs. Or you should then say
> "this system is insecure
Alexander Viro writes:
>
>
> On Fri, 3 Dec 1999, Andrea Arcangeli wrote:
>
> > On Fri, 3 Dec 1999, Richard Gooch wrote:
> >
> > >A hard link is the ideal solution. Many users can "lock" the file so
> > >that they will retain access to it without consuming more space. When
> > >each user has lo
On Fri, 3 Dec 1999, Alexander Viro wrote:
>... and F- on UNIX SA 101 - if you don't know the reasons to keep /tmp on
>a separate filesystem.
Would you call this a solution? This is a very ugly workaround. The fact
this works is only a side effect of the limitations of the hardlink.
So another
On Fri, 3 Dec 1999, Richard Gooch wrote:
>And I want the opposite: I want any user to be able to make hard links
>to my files, without needing write access to the inodes, and without
>needing some stupid set{u|g}id binary.
Any sane workgroup project uses an unix group. You don't need set{u|g}id
On Fri, 3 Dec 1999, Alexander Viro wrote:
>Andrea, you _do_ realize that CODA is not a Linux-only thing? So it's
Have I ever talked about coda in first place?
Andrea
On Fri, Dec 03, 1999 at 12:18:19PM -0500, Alexander Viro wrote:
> On Fri, 3 Dec 1999, Andrea Arcangeli wrote:
>
> > I don't like having only coda breaking the semantic. You'll end getting
> > reports of "program X doesn't work with coda, why?". If you'll break the
> > semantic in the VFS the prog
Hi Linus,
when grab_cache_page was added to kernel, someone who did global
kernel search & replace swapped grab_cache_page and find_lock_page
in ncpfs :-( Because of ncpfs requires page allocation to success,
it did not work as it did find instead of allocation... These
changes are limited to
On Fri, 3 Dec 1999, Andrea Arcangeli wrote:
> On Fri, 3 Dec 1999, Alexander Viro wrote:
>
> >Andrea, you _do_ realize that CODA is not a Linux-only thing? So it's
>
> Have I ever talked about coda in first place?
Oh, great. So your reasons should pass for arbitrary filesystem, right?
Let's s
On Fri, 3 Dec 1999, Andrea Arcangeli wrote:
> On Fri, 3 Dec 1999, Alexander Viro wrote:
>
> >Andrea, WHAT FOR? Give a rationale for your change, other than "let's
> >change it". Name a single benefit of proposed semantics.
>
> The rational is that I don't want to see my inodes sparse around t
Andrea Arcangeli writes:
> On Fri, 3 Dec 1999, Richard Gooch wrote:
>
> >What? Having group write on the directory? No thanks.
>
> You can't hardlink a directory.
Duh. I know that. One proposal was to use access permissions on the
directory to determine if hardlinking was allowed. Yuk.
> I'll
On Fri, 3 Dec 1999, Alexander Viro wrote:
>Andrea, WHAT FOR? Give a rationale for your change, other than "let's
>change it". Name a single benefit of proposed semantics.
The rational is that I don't want to see my inodes sparse around the fs by
an luser. I don't want to find them in /tmp. I don
On Fri, 3 Dec 1999, Richard Gooch wrote:
>What? Having group write on the directory? No thanks.
You can't hardlink a directory.
I'll tell another way that will let you understand correctly for sure.
I want that the i_link of an inode can be changed only by an user that has
write permissions on
On Fri, 3 Dec 1999, Andrea Arcangeli wrote:
> On Fri, 3 Dec 1999, Richard Gooch wrote:
>
> >A hard link is the ideal solution. Many users can "lock" the file so
> >that they will retain access to it without consuming more space. When
> >each user has lost interest, the space is reclaimed.
>
>
Andrea Arcangeli writes:
> On Fri, 3 Dec 1999, Richard Gooch wrote:
>
> >[..] I can definately say that
> >making hardlinks to files in other directories (not owned by the
> >linking user) is a handy feature. [..]
>
> For what exactly is it an handy feature? I never needed to hardlink
> to a fil
On Fri, 3 Dec 1999, Andrea Arcangeli wrote:
> I don't like having only coda breaking the semantic. You'll end getting
> reports of "program X doesn't work with coda, why?". If you'll break the
> semantic in the VFS the program will be fixed ASAP and you'll never get
> the report in the middle o
Andrea Arcangeli writes:
> On Fri, 3 Dec 1999, Richard Gooch wrote:
>
> >A hard link is the ideal solution. Many users can "lock" the file so
> >that they will retain access to it without consuming more space. When
> >each user has lost interest, the space is reclaimed.
>
> You could continue to
On Fri, 3 Dec 1999, Richard Gooch wrote:
>A hard link is the ideal solution. Many users can "lock" the file so
>that they will retain access to it without consuming more space. When
>each user has lost interest, the space is reclaimed.
You could continue to take advantage of the hardlink by usin
[EMAIL PROTECTED] said:
> On Fri, 3 Dec 1999, Richard Gooch wrote:
> > [..] I can definately say that making hardlinks to files in other
> > directories (not owned by the linking user) is a handy feature. [..]
> For what exactly is it an handy feature? I never needed to hardlink to
> a file that
Hello.
Consider following situation:
Process1: Wants to read some page in file. So block_read_full_page() is
called. It gets page but founds it's not uptodate. So we go on page_not_
_uptodate and block.
Process2: Calls truncate on the file. It will capture the i_sem, lower
the size and
On Thu, 2 Dec 1999, Peter J. Braam wrote:
>I think I accept his points, and it's probably not a good idea to put it
>in the VFS.
The nice thing of having it in the VFS is to try to provide the same
semantics to all underlying filesystems. When possible I think we should
make all lowlevel filesys
On Thu, 2 Dec 1999, Martin Dalecki wrote:
>+#define block_write_range(dentry, page, from, len, buf) \
>+ block_write_zero_range(dentry, page, from, from, from+len, buf)
>Ehem. The #define looks lazy. Better do the embedding by an __inline__
>wrapper function.
The define looks fine but it
On Fri, 3 Dec 1999, Richard Gooch wrote:
>[..] I can definately say that
>making hardlinks to files in other directories (not owned by the
>linking user) is a handy feature. [..]
For what exactly is it an handy feature? I never needed to hardlink to a
file that I don't own, so you would convince
"Peter J. Braam" wrote:
> Hi,
>
> Thanks for your comments.
>
> 1. Coda's ctime not set on create is a bug -- I'll send a fix with the
> other 2.3 fixes we will do over the next week or so.
>
> 2. Hard links across directories are not permitted. Jan explained that
> security is an issue here.
>
it would be nice if people who investigate SMP locking issues in VFS would
also contribute their findings to the very nice document on VFS internals
that Neil Brown has written - he accepts patches gladly:
http://www.cse.unsw.edu.au/~neilb/oss/linux-commentary/
Regards,
--
Tigran A. Aivazian
On Fri, 3 Dec 1999, Jeff Garzik wrote:
> What needs to be done before the big kernel lock can moved in favor of
> the finer-grained inode lock?
knfsd cleanup. SMP-safe dcache. SMP-safe namei.c. And quite a bit of
filesystem code.
What needs to be done before the big kernel lock can moved in favor of
the finer-grained inode lock?
Thanks,
Jeff
--
Jeff Garzik | Just once, I wish we would encounter
Building 1024| an alien menace that wasn't immune to
MandrakeSoft, Inc. | bullets.
49 matches
Mail list logo
