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
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
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
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
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
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:
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
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'
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
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
-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 can't be
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
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
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 missing
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?
Yes,
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 except:
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 permission
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
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 and a
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
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 a
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 unsubscribe
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 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 the
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 suggest
otherwise
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 all
We're having a bit of a disagreement with Christoph Hellwig about the
way FUSE does (or should do) permission checking. Comments (either
way) are appreciated.
Here's my side of the story:
FUSE (filesystem in userspace) is designed to allow mounting an FS by
non-privileged users (it can also be
3) No other user should have access to files under the mount, not
even root[5]
[5] Obviously root cannot be restricted, but accidental access to
private data is still a good idea. E.g. root squashing by NFS servers
has a similar affect.
Could you explain a little more? I
On Mon, Apr 11, 2005 at 05:56:09PM +0200, Miklos Szeredi wrote:
3) No other user should have access to files under the mount, not
even root[5]
[5] Obviously root cannot be restricted, but accidental access to
private data is still a good idea. E.g. root squashing by NFS
Miklos Szeredi wrote:
1) User must not be able to modify files or directories in a way
which he otherwise could not do (e.g. mount a filesystem over
/bin)
2) Suid and device semantics should be disabled within the mount
3) No other user should have access to files under
On Mon, Apr 11, 2005 at 07:22:57PM +0100, Jamie Lokier wrote:
1) Only allow mount over a directory for which the user has write
access (and is not sticky)
Seems good - but why not sticky? Mounting a user filesystem in
/tmp/user-xxx/my-mount-point seems not unreasonable - provided
Root squashing is actually a much less obnoxious restriction. It means
that local uid 0 doesn't automatically correspond to remote uid 0.
I don't agree that it's less obnoxious. Root squashing and a
restricted directory (-rwx--) would have exactly the same affect:
root is
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 sysadmin or some automated script of his to go
On Mon, Apr 11, 2005 at 09:56:29PM +0200, Miklos Szeredi wrote:
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
52 matches
Mail list logo
