on den 13.04.2005 Klokka 16:03 (+1000) skreiv Greg Banks:
> Any other issues?
>
> Greg.
Well, I'm sa bit curious as to what "iap->ia_valid |= ATTR_NO_BLOCK"
will do. AFAICS, there is nothing that actually tests for it.
Trond
--
Trond Myklebust <[EMAIL PROTECTED]>
-
To unsubscribe from this li
On Wed, 2005-04-13 at 15:56, Trond Myklebust wrote:
> on den 13.04.2005 Klokka 10:45 (+1000) skreiv Greg Banks:
>
> > There's now a patch to actually do it, see
> >
> > http://marc.theaimsgroup.com/?l=linux-nfs&m=111087383132762&w=2
> >
> > Does anyone want to give a firm yea or nea to this appr
on den 13.04.2005 Klokka 10:45 (+1000) skreiv Greg Banks:
> There's now a patch to actually do it, see
>
> http://marc.theaimsgroup.com/?l=linux-nfs&m=111087383132762&w=2
>
> Does anyone want to give a firm yea or nea to this approach? I'd
> really like to get this patch moving in the pipeline.
On Tue, 12 Apr 2005, Jamie Lokier wrote:
> Bodo Eggert <[EMAIL PROTECTED]> wrote:
> > > I think that would be _much_ nicer implemented as a mount which is
> > > invisible to other users, rather than one which causes the admin's
> > > scripts to spew error messages. Is the namespace mechanism at a
On Tue, 12 Apr 2005, Jamie Lokier wrote:
> Bodo Eggert <[EMAIL PROTECTED]> wrote:
> > Jamie Lokier <[EMAIL PROTECTED]> wrote:
> > > Miklos Szeredi wrote:
> >
> > >> 4) Access should not be further restricted for the owner of the
> > >> mount, even if permission bits, uid or gid would sugges
G'day,
On Sat, 2004-03-20 at 20:24, Greg Banks wrote:
> Jamie Lokier wrote:
> > Christoph Hellwig wrote:
> > > It's used to [...] return EAGAIN to the nfs server so it doesn't block all
> > > nfsd threads on possible long-enduring HSM operations.
> >
> > How does nfsd get notified when the operat
On Mon, 11 Apr 2005, Jamie Lokier wrote:
> Miklos Szeredi wrote:
> > That is exactly the intended effect. If I'm at my work machine (where
> > I'm not an admin unfortunately) and I mount my home machine with sshfs
> > (because FUSE is installed fortunately :), then I bloody well don't
> > want the
Anton Altaparmakov wrote:
> > That said, I would _usually_ prefer that when I enter a tgz, that I
> > see all component files having the same uid/gid/permissions as the tgz
> > file itself - the same as I'd see if I entered a zip file.
>
> As you say _usually_, even you admit that sometimes you wo
> > Still can't find it :)
> >
> > Which kernel? Which file?
>
> I'm looking at linux-2.4.30/fs/nfs/dir.c.
Ahh, OK.
nfs_permission() in 2.6 looks quite a bit different. And permission
bits are not used if ->access() is available.
Miklos
-
To unsubscribe from this list: send the line "unsubsc
> There was a thread a few months ago where file-as-directory was
> discussed extensively, after Namesys implemented it. That's where the
> conversation on detachable mount points originated AFAIR. It will
> probably happen at some point.
>
> A nice implemention of it in FUSE could push it along
> > I can accept that usually you are not interested in the stored
> > uid/gid. But doubt that you want to lose permission information when
> > you mount a tar file. Zip is a different kettle of fish since that
> > doesn't contain uid/gid/permissions.
>
> It's not about being not interested.
>
Miklos Szeredi wrote:
> Still can't find it :)
>
> Which kernel? Which file?
I'm looking at linux-2.4.30/fs/nfs/dir.c.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org
Miklos Szeredi wrote:
> > Indeed, if it can be done with namespaces _and_ mounting on a file
> > (that file-as-directory concept), _and_ automounting, then you could
> > cd into your tgz files and others could too :)
>
> There's still that little problem of accessing the tgz file both as a
> file
Miklos Szeredi wrote:
> > Yes, for NFSv2, this test in nfs_permssion():
> >
> > if (!NFS_PROTO(inode)->access)
> > goto out;
>
> I've seen that, I just thought that was for some broken servers not
> for all NFSv2 servers.
>
> Anyway that's been fixed in NFSv3, so obviously the "p
Miklos Szeredi wrote:
> The same can be true for tarfs. I mount it for my purpose, others can
> mount it for theirs. Since the daemon providing the filesystem asways
> runs with the same capabilities as the user who did the mount, I and
> others will always get the permissions that we have on the
> >
> > > And for either version of NFS, if the uid and gid are non-zero, and
> > > the permission bits indicate that an access is permitted, then the
> > > client does not consult the server for permission.
> >
> > Where's that? I see no such check.
>
> /*
>* Trust UNIX mode bits
> Indeed, if it can be done with namespaces _and_ mounting on a file
> (that file-as-directory concept), _and_ automounting, then you could
> cd into your tgz files and others could too :)
There's still that little problem of accessing the tgz file both as a
file and a directory. But yes. Maybe
On Tue, Apr 12, 2005 at 17:13:03 +0100, Jamie Lokier wrote:
> Miklos Szeredi wrote:
> > > Note that NFS checks the permissions on _both_ the client and server,
> > > for a reason.
> >
> > Does it? If I read the code correctly the client checks credentials
> > supplied by the server (or cached).
> > > Note that NFS checks the permissions on _both_ the client and server,
> > > for a reason.
> >
> > Does it? If I read the code correctly the client checks credentials
> > supplied by the server (or cached). But the server does the actual
> > checking of permissions.
> >
> > Am I missing so
Miklos Szeredi wrote:
> > Note that NFS checks the permissions on _both_ the client and server,
> > for a reason.
>
> Does it? If I read the code correctly the client checks credentials
> supplied by the server (or cached). But the server does the actual
> checking of permissions.
>
> Am I miss
Miklos Szeredi wrote:
> > If the user wants to edit a read-only file in a tgz owned by himself,
> > why can he not _chmod_ the file and _then_ edit it?
> >
> > That said, I would _usually_ prefer that when I enter a tgz, that I
> > see all component files having the same uid/gid/permissions as the
> For 1) your porposal makes sense, however for 2) it's useless, since
> now the user doesn't want the hiding.
I realize that the idea _could_ be used to drop 'allow_root' mount
option from the kernel. Since 'allow_root' doesn't add any security
over 'allow_other' it's safe to do it in userspace.
Frank Sorenson wrote:
> > That does not make sense.
> >
> > Are you saying you cannot trust your own sshfs userspace daemon?
>
> The user who wrote the userspace code may be able to, but the system
> shouldn't trust the userspace daemon. Permissions will be enforced by
> the ssh server.
In fact
> Note that NFS checks the permissions on _both_ the client and server,
> for a reason.
Does it? If I read the code correctly the client checks credentials
supplied by the server (or cached). But the server does the actual
checking of permissions.
Am I missing something?
Thanks,
Miklos
-
To un
Bodo Eggert <[EMAIL PROTECTED]> wrote:
> >> That is exactly the intended effect. If I'm at my work machine (where
> >> I'm not an admin unfortunately) and I mount my home machine with sshfs
> >> (because FUSE is installed fortunately :), then I bloody well don't
> >> want the sysadmin or some auto
> > > With that, the desire for virtual filesystems which cannot be read
> > > by your sysadmin (by accident) is easy to satisfy - and that kind of
> > > mechanism would probably be acceptable to all.
> >
> > The problem is that this way the responsibility goes to the userspace
> > program, which
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jamie Lokier wrote:
> That does not make sense.
>
> Are you saying you cannot trust your own sshfs userspace daemon?
The user who wrote the userspace code may be able to, but the system
shouldn't trust the userspace daemon. Permissions will be enfor
> If the user wants to edit a read-only file in a tgz owned by himself,
> why can he not _chmod_ the file and _then_ edit it?
>
> That said, I would _usually_ prefer that when I enter a tgz, that I
> see all component files having the same uid/gid/permissions as the tgz
> file itself - the same as
Bodo Eggert <[EMAIL PROTECTED]> wrote:
> Jamie Lokier <[EMAIL PROTECTED]> wrote:
> > Miklos Szeredi wrote:
>
> >> 4) Access should not be further restricted for the owner of the
> >> mount, even if permission bits, uid or gid would suggest
> >> otherwise
> >
> > Why? Surely you want
Miklos Szeredi wrote:
> The same is true for the case when you mount an sshfs. Since you
> entered your password (or have a passwordless login to the server) you
> are authorized to browse the files on the server, but only with the
> capabilities you have there as a user. The server does the
> au
Miklos Szeredi wrote:
> > It would also be nice to generalise and have virtual filesystems which
> > are able to present different views to different users. Can FUSE do
> > that already - is the userspace part told which user is doing each
> > operation?
>
> Yes.
>
> > With that, the desire for
On Mon, 11 Apr 2005, Jeff Moyer wrote:
Glad you were able to find time to review the patches Jeff.
Much appreciated.
==> Regarding [PATCH 1/3] autofs4 - expiring filesystem from under process;
[EMAIL PROTECTED] adds:
raven> autofs4-2.6.12-rc1-mm4-wait-order.patch
raven> It's possible for an event
Jamie Lokier <[EMAIL PROTECTED]> wrote:
> Miklos Szeredi wrote:
>> 4) Access should not be further restricted for the owner of the
>> mount, even if permission bits, uid or gid would suggest
>> otherwise
>
> Why? Surely you want to prevent writing to files which don't have the
> writ
On Mon, Apr 11, 2005 at 17:56:09 +0200, Miklos Szeredi wrote:
> > Could you explain a little more? I don't see the point in denying
> > access to root, but I also can't tell from your explanation whether you
> > do or not.
>
> Fuse by default does. This can be disabled by one of two mount
> opti
34 matches
Mail list logo
