>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).
>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.
>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.
>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.
Andrea
-
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/