[cc: list trimmed]
On Sun, Dec 12, 1999 at 01:24:17AM -0600, Peter Samuelson wrote:
> And, in general, any time you want the file *gone* more than you want
> it *unlinked*. If you don't have write access to the directory, for
> example, -T will at least truncate the file.
>
> I thought about a
[Pavel Machek <[EMAIL PROTECTED]>]
> > > I still think that adding feature to truncate file before deletion
> > > into rm would make you happy, Andrea. That handles both open() and
> > > link() cases nicely.
[me]
> > I agree. Something like this? (Lightly tested.)
[Pavel Machek]
> YES! T
Hi!
> [Pavel Machek <[EMAIL PROTECTED]>]
> > I still think that adding feature to truncate file before deletion
> > into rm would make you happy, Andrea. That handles both open() and
> > link() cases nicely.
>
> I agree. Something like this? (Lightly tested.)
YES! That should stop andrea comp
[Pavel Machek <[EMAIL PROTECTED]>]
> I still think that adding feature to truncate file before deletion
> into rm would make you happy, Andrea. That handles both open() and
> link() cases nicely.
I agree. Something like this? (Lightly tested.)
Peter
diff -urN fileutils-4.0/src.orig/mv.c file
On 9 Dec 1999, Kjetil Torgrim Homme wrote:
> [Alexander Viro]
>
> > Huh? If attacker can link something outside of chroot jail you
> > are _already_ screwed - he can just access it directly.
>
> A local user can make restricted files available for anonymous FTP if
> he has write access
[Alexander Viro]
> Huh? If attacker can link something outside of chroot jail you
> are _already_ screwed - he can just access it directly.
A local user can make restricted files available for anonymous FTP if
he has write access somewhere inside the jail. A bit far fetched, I
admit. A
On 9 Dec 1999, Kjetil Torgrim Homme wrote:
> [Alexander Viro]
>
> > Again, until you've removed your link _other_ links do not
> > matter. And once you've removed it it will not be used to create
> > new ones anyway. I still don't see anything you could buy
> > prohibiting link().
[Alexander Viro]
> Again, until you've removed your link _other_ links do not
> matter. And once you've removed it it will not be used to create
> new ones anyway. I still don't see anything you could buy
> prohibiting link().
Think chroot(). Think chmod() (by the admin after the
> Hi!
>
> > But the fact that we don't have a working revoke() is the more important
> > problem. Forget local attacks. What about telnet to port 80, type GET
> > /~user/bigassgif.gif, and hit ^]^Z so the transfer will never finish? rm
> > needs some teeth for such situations.
>
> You don't need
Andrea Arcangeli <[EMAIL PROTECTED]> wrote:
> 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 me if you would raise
> good points.
cp -la is rather handy when doing test builds. And you can easily
wind up not owning the file
Hi!
> >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 enough it doesn't mean it's in
Hi!
> But the fact that we don't have a working revoke() is the more important
> problem. Forget local attacks. What about telnet to port 80, type GET
> /~user/bigassgif.gif, and hit ^]^Z so the transfer will never finish? rm
> needs some teeth for such situations.
You don't need revoke() to do
On Fri, 3 Dec 1999, Andrea Arcangeli wrote:
> I want that the i_link of an inode can be changed only by an user that has
> write permissions on the inode. I don't care if the permissions cames from
> the uid/gid/other settings in the inode.
>
> I don't want an luser to increase the i_link of my i
On Sun, 5 Dec 1999, Alexander Viro wrote:
>Good luck dealing with that.
Thank you.
In this moment I am busy with other more priority stuff but of course it's
just in my todo list.
Andrea
On Sun, 5 Dec 1999, Alan Curry wrote:
> Alexander Viro writes the following:
> >
> >On Fri, 3 Dec 1999, Pavel Machek wrote:
> >
> >> Is not this bug of fuser? I mean, if someone has file opened, should
> >> not it be visible by fuser?
> >
> >The whole point being that _nobody_ has it opened. It
Alexander Viro writes the following:
>
>On Fri, 3 Dec 1999, Pavel Machek wrote:
>
>> Is not this bug of fuser? I mean, if someone has file opened, should
>> not it be visible by fuser?
>
>The whole point being that _nobody_ has it opened. It was attached to a
Still, it's a bug if this information
I answered this privately. Richard wasn't the only rude person. let's try to
speak to people like we would if face-to-face, shall we?
Email escapes our wiser social instincts.
Hans
Richard Gooch wrote:
> Hans Reiser writes:
> > Ok, I read the whole thread, and good reasons were g
Hans Reiser writes:
> Ok, I read the whole thread, and good reasons were given why it was bad, so I won't
> put it in.
>
> Also, if you are going to swear, then swear, or don't swear. References to fsck are
> pretty unpleasant to read.;-)
>
> And when Richard accuses someone else in this thread
Ok, I read the whole thread, and good reasons were given why it was bad, so I won't
put it in.
Also, if you are going to swear, then swear, or don't swear. References to fsck are
pretty unpleasant to read.;-)
And when Richard accuses someone else in this thread of being rude to people, it's
pre
Pavel Machek <[EMAIL PROTECTED]> said:
[That was a bit of exessive crossposting, IMHO]
> In-Reply-To: <[EMAIL PROTECTED]>; from Andr
> ***ea Arcangeli on Fri, Dec 03, 1999 at 01:48:01AM +0100
> > >Don't bring the policy question into the kernel. If you want to kill the
> > >contents of inode
On Sun, 5 Dec 1999, Alexander Viro wrote:
>The whole point being that _nobody_ has it opened. It was attached to a
>packet when sender called sendmsg(). That is, set of descriptors passed
>by caller of sendmsg() had been converted into the set of struct file *
>When recvmsg() is called by the rec
In message <[EMAIL PROTECTED]>, Pavel Machek writes:
+-
| You might want to put file called rm containing this
|
| #!/bin/bash
| > $1; rm $1
+--->8
"/bin/rm" there, unless you like fork bombs.
--
brandon s. allbery os/2,linux,solaris,perl [EMAIL PROTECTED]
system administrator
On Fri, 3 Dec 1999, Pavel Machek wrote:
> Is not this bug of fuser? I mean, if someone has file opened, should
> not it be visible by fuser?
The whole point being that _nobody_ has it opened. It was attached to a
packet when sender called sendmsg(). That is, set of descriptors passed
by caller
Hi!
> > I completly agree with you that the suid hardlink issue is not a good
> > point for the above issues. Doing >suid is the right thing to do.
> >
> > But for the quota forbidding the hardlink in such case is a good point
> > IMHO.
>
> Same mechanism. If I see that foo is nearing the quota
Hi!
> >Don't bring the policy question into the kernel. If you want to kill the
> >contents of inode - unlink() is _not_ a way to go. truncate() is.
>
> What have unlink() or truncate() to do with this issue? The only system
> call we are talking about is _link_(2).
He's telling you to use > $1
Alan Curry writes:
> Richard Gooch writes the following:
> >
> >This misses the point. The proposed change would require me to make my
> >inodes writable by others in order to let them make hard links. That's
> >much worse than the problem you're concerned about.
>
> If you environment is suffici
Richard Gooch writes the following:
>
>This misses the point. The proposed change would require me to make my
>inodes writable by others in order to let them make hard links. That's
>much worse than the problem you're concerned about.
If you environment is sufficiently non-hostile that you don't
Alan Curry writes:
> 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 m
[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
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
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 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.
>
Peter J. Braam writes:
>
> Let's just take one step back.
>
> Al has successfully pointed out that one should not expect too much in
> terms of security improvements for my hardlink suggestion.
>
> Al additionally gave two reasons, totally unrelated to the security
> issues, not to implemen
Let's just take one step back.
Al has successfully pointed out that one should not expect too much in
terms of security improvements for my hardlink suggestion.
Al additionally gave two reasons, totally unrelated to the security
issues, not to implement the link semantics as I suggested:
On Fri, 3 Dec 1999, Andrea Arcangeli wrote:
> I completly agree with you that the suid hardlink issue is not a good
> point for the above issues. Doing >suid is the right thing to do.
>
> But for the quota forbidding the hardlink in such case is a good point
> IMHO.
Same mechanism. If I see t
On Thu, 2 Dec 1999, Alexander Viro wrote:
>such games link() is the least of your problems - it's effect can be
>completely reproduced with plain open(). exec 42hours after that sh -c /dev/fd/42 will do the trick - fork() preserves
>open descriptors.
If there was really a security hole the intru
On Fri, 3 Dec 1999, Andrea Arcangeli wrote:
> On Thu, 2 Dec 1999, Alexander Viro wrote:
>
> >Don't bring the policy question into the kernel. If you want to kill the
> >contents of inode - unlink() is _not_ a way to go. truncate() is.
>
> What have unlink() or truncate() to do with this issue
On Thu, 2 Dec 1999, Alexander Viro wrote:
>Don't bring the policy question into the kernel. If you want to kill the
>contents of inode - unlink() is _not_ a way to go. truncate() is.
What have unlink() or truncate() to do with this issue? The only system
call we are talking about is _link_(2).
On Thu, 2 Dec 1999, Peter J. Braam wrote:
> > Effectively open does the same wrt keeping file alive. So?
>
> I have said nothing about open - just about link.
... and anything that relies on unlink() as mechanism to remove the file
contents is broken, so prohibiting link() alone will not cha
Because the access control is on directories only,
it will be hard to know precisely what access is
permitted to any file with link count > 1.
Per-file ACLs do make this much clearer, despite
the cost.
> Hard links are incredibly useful and it make no sense to
> disable them only
> for secur
> On Wed, 1 Dec 1999, Peter J. Braam wrote:
>
> > 2. Hard links across directories are not permitted. Jan explained that
> > security is an issue here.
> >
> > I think there is wrong thinking in the way Unix does things normally and
> > the security argument goes away when the following reas
On Thu, 2 Dec 1999, Andrea Arcangeli wrote:
> > - process can modify the attributes of the file it wants to link
>
> This must be enforced to achieve security (also the very silly quota issue
> will be addressed), I agree with you. I agree to change this. I also don't
> think the breakage wou
On Wed, 1 Dec 1999, Peter J. Braam wrote:
> 2. Hard links across directories are not permitted. Jan explained that
> security is an issue here.
>
> I think there is wrong thinking in the way Unix does things normally and
> the security argument goes away when the following reasoning is foll
On Wed, 1 Dec 1999, Peter J. Braam wrote:
>2. Hard links across directories are not permitted. Jan explained that
>security is an issue here.
>
>I think there is wrong thinking in the way Unix does things normally and
>the security argument goes away when the following reasoning is followed.
>
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.
I think there is wrong thinking in the
84 matches
Mail list logo
