Messages in this thread | | | Date | Fri, 3 Dec 1999 15:24:45 -0700 | From | Richard Gooch <> | Subject | Re: Can't hardlink in different dirs. (BUG#826) |
| |
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 unix group. You don't need > set{u|g}id binaries. Just use the right GID settings on files and on > users (basic admin docs explain how to do that while explainig > chgrp/chown/newgrp and the unix file permissions).
I don't want *anyone* writing to my inodes! But I do want them to be able to hardlink to them.
And Andrea: why do you keep pointing me to "basic admin docs" or basic Unix permissions info? Are you trying to be rude?
> >Maybe you work in a hostile environment, but I (usually) work in a > >co-operative environment. That usually means no quotas, most > >directories readable and executable by everyone and so on. > > 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 and you should run it only > in an envinroment like mine". Personally I like linux to be secure > and to be safe enough to run also in very very hostile environments.
*I* haven't suggested removing anything. You're the one who is suggesting that functionality be removed/restricted. I'm advocating that things not be changed, since it works for co-operative environments as well as very very hostile environments.
Again: if you're worried about hard links, lock up your directories. That's all you need to do.
> >The changes you propose prevent efficient work in a co-operative > >environment. Thus it's a bad idea. > > So you want to remove also the permission from files and let > everybody to open/read/write to all files? It will also avoid you > having to use chgrp on files that you want to share with other users > while working in a co-operative environment.
Where do you get this stuff from? Nowhere have I suggested that permissions checking should be removed. There is no logical connection between what I've been saying and what you say above.
I can't imagine where you get this chgrp "requirement" from. You seem to be implying that I need to do that today to share data. Well, I can't even remember the last time I (as a user) have called chgrp.
> >In that case there's no conceivable reason to change the VFS. Nor any > > There's no way I would add an hack in the vfs to simplify an fs that > is just smart enough. I don't see your point.
You've snipped the relevant context.
Regards,
Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |