Mike Waychison <[EMAIL PROTECTED]> wrote:
> Consider the following pseudo example:
>
> main():
> chdir("/");
> fd = open(".", O_RDONLY);
> clone(cloned_func, cloned_stack, CLONE_NEWNS, NULL);
>
> cloned_func:
> fchdir(fd);
> chdir("..");
>
> if main is run within a chroot where it's "/" is on
> Likely because its a chroot vulnerability.
>
> It allows a process to obtain a reference to the root vfsmount that
> doesn't have chroot checks performed on it.
>
> Consider the following pseudo example:
>
[...]
>
> if main is run within a chroot where it's "/" is on the same vfsmount as
>
Likely because its a chroot vulnerability.
It allows a process to obtain a reference to the root vfsmount that
doesn't have chroot checks performed on it.
Consider the following pseudo example:
[...]
if main is run within a chroot where it's / is on the same vfsmount as
it's .., then
Mike Waychison [EMAIL PROTECTED] wrote:
Consider the following pseudo example:
main():
chdir(/);
fd = open(., O_RDONLY);
clone(cloned_func, cloned_stack, CLONE_NEWNS, NULL);
cloned_func:
fchdir(fd);
chdir(..);
if main is run within a chroot where it's / is on the same vfsmount as
Eric Van Hensbergen wrote:
> Somewhat related question for Viro/the group:
>
> Why is CLONE_NEWNS considered a priveledged operation? Would placing
> limits on the number of private namespaces a user can own solve any
> resource concerns or is there something more nefarious I'm missing?
> -
> To
Somewhat related question for Viro/the group:
Why is CLONE_NEWNS considered a priveledged operation? Would placing
limits on the number of private namespaces a user can own solve any
resource concerns or is there something more nefarious I'm missing?
-
To unsubscribe from this list: send the
On Tue, 19 Apr 2005, Eric Van Hensbergen wrote:
> On 4/19/05, Bodo Eggert <[EMAIL PROTECTED]> wrote:
> > Allowing user mounts with no* should be allways ok (no config needed
> > besides the ulimit), and mounting specified files to defined locations
> > is allready supported by fstab.
> >
>
> Do
On 4/19/05, Bodo Eggert <[EMAIL PROTECTED]> wrote:
> >
> > Well, that would kinda be the intent behind the permissions file --
> > it can specify what restricted set of images/devices/whatever the user
> > can mount, I suppose the sensible thing would be to always enforce
> > nosuid and nsgid,
>
> I think you shouldn't help the admins by creating shoes with target marks.
>
> Allowing user mounts with no* should be allways ok (no config needed
> besides the ulimit), and mounting specified files to defined locations
> is allready supported by fstab.
I tend to agree. It should be
On Tue, 19 Apr 2005, Eric Van Hensbergen wrote:
> On 4/17/05, Bodo Eggert <[EMAIL PROTECTED]>
> > > I was thinking about this a while back and thought having a user-mount
> > > permissions file might be the right way to address lots of these
> > > issues. Essentially it would contain information
On 4/17/05, Bodo Eggert <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> wrote:
>
> > I was thinking about this a while back and thought having a user-mount
> > permissions file might be the right way to address lots of these
> > issues. Essentially it would contain information about what
> >
On 4/17/05, Bodo Eggert [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
I was thinking about this a while back and thought having a user-mount
permissions file might be the right way to address lots of these
issues. Essentially it would contain information about what
users/groups were
On Tue, 19 Apr 2005, Eric Van Hensbergen wrote:
On 4/17/05, Bodo Eggert [EMAIL PROTECTED]
I was thinking about this a while back and thought having a user-mount
permissions file might be the right way to address lots of these
issues. Essentially it would contain information about what
I think you shouldn't help the admins by creating shoes with target marks.
Allowing user mounts with no* should be allways ok (no config needed
besides the ulimit), and mounting specified files to defined locations
is allready supported by fstab.
I tend to agree. It should be obvious
On 4/19/05, Bodo Eggert [EMAIL PROTECTED] wrote:
Well, that would kinda be the intent behind the permissions file --
it can specify what restricted set of images/devices/whatever the user
can mount, I suppose the sensible thing would be to always enforce
nosuid and nsgid, but I'd rather
On Tue, 19 Apr 2005, Eric Van Hensbergen wrote:
On 4/19/05, Bodo Eggert [EMAIL PROTECTED] wrote:
Allowing user mounts with no* should be allways ok (no config needed
besides the ulimit), and mounting specified files to defined locations
is allready supported by fstab.
Do folks think
Somewhat related question for Viro/the group:
Why is CLONE_NEWNS considered a priveledged operation? Would placing
limits on the number of private namespaces a user can own solve any
resource concerns or is there something more nefarious I'm missing?
-
To unsubscribe from this list: send the
Eric Van Hensbergen wrote:
Somewhat related question for Viro/the group:
Why is CLONE_NEWNS considered a priveledged operation? Would placing
limits on the number of private namespaces a user can own solve any
resource concerns or is there something more nefarious I'm missing?
-
To
Eric Van Hensbergen <[EMAIL PROTECTED]> wrote:
> On 4/11/05, Miklos Szeredi <[EMAIL PROTECTED]> wrote:
>>
>> 1) Only allow mount over a directory for which the user has write
>> access (and is not sticky)
>>
>> 2) Use nosuid,nodev mount options
[...]
> Do these solve all the security
On 4/17/05, Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > >
> > > 1) Only allow mount over a directory for which the user has write
> > > access (and is not sticky)
> > >
> > > 2) Use nosuid,nodev mount options
> > >
> > > [ parts deleted ]
> >
> > Do these solve all the security concerns
> >
> > 1) Only allow mount over a directory for which the user has write
> > access (and is not sticky)
> >
> > 2) Use nosuid,nodev mount options
> >
> > [ parts deleted ]
>
> Do these solve all the security concerns with unprivileged mounts, or
> are there other barriers/concerns?
Eric Van Hensbergen wrote:
> I'd like to second that I think private-namespaces are the right way
> to solve this sort of problem. It also helps not cluttering the
> global namespace with user-local mounts
>
> >
> > Shared subtrees and more support in userspace tools is needed before
> > private
On 4/11/05, Miklos Szeredi <[EMAIL PROTECTED]> wrote:
>
> 1) Only allow mount over a directory for which the user has write
> access (and is not sticky)
>
> 2) Use nosuid,nodev mount options
>
> [ parts deleted ]
Do these solve all the security concerns with unprivileged mounts, or
On 4/12/05, Miklos Szeredi <[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 all suitable for that?
>
>
On 4/12/05, Miklos Szeredi [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 all suitable for that?
It is
On 4/11/05, Miklos Szeredi [EMAIL PROTECTED] wrote:
1) Only allow mount over a directory for which the user has write
access (and is not sticky)
2) Use nosuid,nodev mount options
[ parts deleted ]
Do these solve all the security concerns with unprivileged mounts, or
are there
Eric Van Hensbergen wrote:
I'd like to second that I think private-namespaces are the right way
to solve this sort of problem. It also helps not cluttering the
global namespace with user-local mounts
Shared subtrees and more support in userspace tools is needed before
private
1) Only allow mount over a directory for which the user has write
access (and is not sticky)
2) Use nosuid,nodev mount options
[ parts deleted ]
Do these solve all the security concerns with unprivileged mounts, or
are there other barriers/concerns? Should there be
On 4/17/05, Miklos Szeredi [EMAIL PROTECTED] wrote:
1) Only allow mount over a directory for which the user has write
access (and is not sticky)
2) Use nosuid,nodev mount options
[ parts deleted ]
Do these solve all the security concerns with unprivileged mounts,
Eric Van Hensbergen [EMAIL PROTECTED] wrote:
On 4/11/05, Miklos Szeredi [EMAIL PROTECTED] wrote:
1) Only allow mount over a directory for which the user has write
access (and is not sticky)
2) Use nosuid,nodev mount options
[...]
Do these solve all the security concerns with
> > > Yet, the results from stat() don't distinguish the number spaces,
> > > and "ls" doesn't map the numbers to names properly in the wrong
> > > space.
> >
> > Well you can use "ls -n". It's up to the tools to present the
> > information you want in the way you want it. If a tool can't do
Miklos Szeredi wrote:
> > Yet, the results from stat() don't distinguish the number spaces,
> > and "ls" doesn't map the numbers to names properly in the wrong
> > space.
>
> Well you can use "ls -n". It's up to the tools to present the
> information you want in the way you want it. If a tool
> > I have a little project to imlement a "userloop" filesystem, which
> > works just like "mount -o loop", but you don't need root privs. This
> > is really simple to do with FUSE and UML.
>
> That would be a nice way to implement those rarely used old
> filesystems that aren't really needed in
Miklos Szeredi wrote:
> I have a little project to imlement a "userloop" filesystem, which
> works just like "mount -o loop", but you don't need root privs. This
> is really simple to do with FUSE and UML.
That would be a nice way to implement those rarely used old
filesystems that aren't really
Miklos Szeredi wrote:
> > Look up the rather large linux-kernel & linux-fsdevel thread "silent
> > semantic changes with reiser4" and it's followup threads, from last
> > year.
>
> Wow, it's 700+ messages. I got through the first 40, and already feel
> dizzy :)
It's easier if you skip the ones
> Look up the rather large linux-kernel & linux-fsdevel thread "silent
> semantic changes with reiser4" and it's followup threads, from last
> year.
Wow, it's 700+ messages. I got through the first 40, and already feel
dizzy :)
> It's already been tried. You will also find sensible ideas on
Miklos Szeredi wrote:
> > > Aren't there some assumptions in VFS that currently make this
> > > impossible?
> >
> > I believe it's OK with VFS, but applications would be confused to death.
> > Well, there really is one issue -- dentries have exactly one parent, so
> > what do you do when opening
> > > A nice implemention of it in FUSE could push it along a bit :)
> >
> > Aren't there some assumptions in VFS that currently make this
> > impossible?
>
> I believe it's OK with VFS, but applications would be confused to death.
> Well, there really is one issue -- dentries have exactly one
> > Aren't there some assumptions in VFS that currently make this
> > impossible?
>
> I believe it's OK with VFS, but applications would be confused to death.
> Well, there really is one issue -- dentries have exactly one parent, so
> what do you do when opening a file with hardlinks as a
On Wed, Apr 13, 2005 at 11:14:10 +0200, Miklos Szeredi wrote:
> > > There are uses for both. For example today I was updating the tar ball
> > > which is used to create the var file system for a new chroot. I
> > > certainly
> > > want to see corretly setup owner/permissions when I look into
On Tue, Apr 12, 2005 at 21:08:25 +0200, Miklos Szeredi wrote:
> > 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
> > There are uses for both. For example today I was updating the tar ball
> > which is used to create the var file system for a new chroot. I certainly
> > want to see corretly setup owner/permissions when I look into that tar
> > ball using a FUSE fs...
>
> If I'm updating a var filesystem
There are uses for both. For example today I was updating the tar ball
which is used to create the var file system for a new chroot. I certainly
want to see corretly setup owner/permissions when I look into that tar
ball using a FUSE fs...
If I'm updating a var filesystem for a new
On Tue, Apr 12, 2005 at 21:08:25 +0200, Miklos Szeredi wrote:
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
On Wed, Apr 13, 2005 at 11:14:10 +0200, Miklos Szeredi wrote:
There are uses for both. For example today I was updating the tar ball
which is used to create the var file system for a new chroot. I
certainly
want to see corretly setup owner/permissions when I look into that tar
Aren't there some assumptions in VFS that currently make this
impossible?
I believe it's OK with VFS, but applications would be confused to death.
Well, there really is one issue -- dentries have exactly one parent, so
what do you do when opening a file with hardlinks as a directory? (In
A nice implemention of it in FUSE could push it along a bit :)
Aren't there some assumptions in VFS that currently make this
impossible?
I believe it's OK with VFS, but applications would be confused to death.
Well, there really is one issue -- dentries have exactly one parent, so
Miklos Szeredi wrote:
Aren't there some assumptions in VFS that currently make this
impossible?
I believe it's OK with VFS, but applications would be confused to death.
Well, there really is one issue -- dentries have exactly one parent, so
what do you do when opening a file with
Look up the rather large linux-kernel linux-fsdevel thread silent
semantic changes with reiser4 and it's followup threads, from last
year.
Wow, it's 700+ messages. I got through the first 40, and already feel
dizzy :)
It's already been tried. You will also find sensible ideas on what
Miklos Szeredi wrote:
Look up the rather large linux-kernel linux-fsdevel thread silent
semantic changes with reiser4 and it's followup threads, from last
year.
Wow, it's 700+ messages. I got through the first 40, and already feel
dizzy :)
It's easier if you skip the ones by Hans and
Miklos Szeredi wrote:
I have a little project to imlement a userloop filesystem, which
works just like mount -o loop, but you don't need root privs. This
is really simple to do with FUSE and UML.
That would be a nice way to implement those rarely used old
filesystems that aren't really needed
I have a little project to imlement a userloop filesystem, which
works just like mount -o loop, but you don't need root privs. This
is really simple to do with FUSE and UML.
That would be a nice way to implement those rarely used old
filesystems that aren't really needed in the kernel
Miklos Szeredi wrote:
Yet, the results from stat() don't distinguish the number spaces,
and ls doesn't map the numbers to names properly in the wrong
space.
Well you can use ls -n. It's up to the tools to present the
information you want in the way you want it. If a tool can't do that,
Yet, the results from stat() don't distinguish the number spaces,
and ls doesn't map the numbers to names properly in the wrong
space.
Well you can use ls -n. It's up to the tools to present the
information you want in the way you want it. If a tool can't do that,
tough, but
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
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
> > 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
> 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
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
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
> > > 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
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-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
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:
> 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
> >
> > > 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
> 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).
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
> > 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:
> > 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
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
> 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
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
> 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
-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
> > > 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
> 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
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
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
>
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
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
>
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
>
> > Well the sanity check on the "server" side is always enforced. You
> > can't "trick" sftp or ftp to not check permissions. So checking on
> > the "client" side too (where the fuse daemon is running) makes no
> > sense, does it?
>
> That argument doesn't make much sense to me. But we're at
> 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.
Spew is a strong word. It'll get a single EACCES at the mountpoint.
The same is true for directories not accessible by
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.
Spew is a strong word. It'll get a single EACCES at the mountpoint.
The same is true for directories not accessible by 'nobody'
Well the sanity check on the server side is always enforced. You
can't trick sftp or ftp to not check permissions. So checking on
the client side too (where the fuse daemon is running) makes no
sense, does it?
That argument doesn't make much sense to me. But we're at the end of
my
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
options:
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
writable bit
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 virtual
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
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 to prevent writing
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 automated script
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
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 can't be
-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
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 I'd
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 that's
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.
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 tgz
1 - 100 of 142 matches
Mail list logo
