otherwise.
I can think of plenty of uses for this.
> 4) Access should not be further restricted for the owner of the
> mount, even if permission bits, uid or gid would suggest
> otherwise
Similar questions.
--
Daniel Jacobowitz
CodeSourcery, LLC
-
To unsubscribe from this list:
ault_permissions".
But why does the kernel need to know anything about this? Why can't
the userspace library present the permissions appropriately to the
kernel? I'm going to be pretty confused if I see a mode 666 file that
I can't even read. So will various programs.
Exc
eems not unreasonable - provided the
> administrator can delete the directory (which is possible with
> detachable mount points).
Because then they could mount over /tmp. "and (is not sticky || is
owned by the user)" may be more appropriate.
--
Daniel Jacobowitz
CodeSourcery, LLC
-
To
les that the user has requested no
other users be able to write as unwritable by group/other? Sure, it
makes your tarfs a little less mapped onto the tar file. But that's
one of the recurring objections to implementing archivers as
filesystems: the ownership in the archive is _not_ relevant to
is running) makes no
> sense, does it?
That argument doesn't make much sense to me. But we're at the end of
my useful contributions to this discussion; I'm going to be quiet now
and hope some folks who know more about filesystems have more useful
responses.
--
Daniel Jacobowitz
Co
