lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 16 Jul 2006 08:19:32 -0400
From:	Kyle Moffett <mrmacman_g4@....com>
To:	Al Boldi <a1426z@...ab.com>
Cc:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH -mm 5/7] add user namespace

On Jul 15, 2006, at 13:39:50, Al Boldi wrote:
> Trond Myklebust wrote:
>> On Sat, 2006-07-15 at 06:35 -0600, Eric W. Biederman wrote:
>>> I hope the confusion has passed for Trond.  My impression was he  
>>> figured this was per process data so it didn't make sense any  
>>> where near a filesystem, and the superblock was the last place it  
>>> should be.
>>
>> You are still using the wrong abstraction. Data that is not global  
>> to the entire machine has absolutely _no_ place being put into the  
>> superblock. It doesn't matter if it is process-specific, container- 
>> specific or whatever-else-specific, it will still be vetoed.
>>
>> If your real problem is uid/gid mapping on top of generic  
>> filesystems, then have you looked into the *BSD solution of using  
>> a stackable filesystem (i.e. umapfs)?
>
> A stackable FS is really overkill here, when all that is needed is  
> a simple mapping.  An easy solution would be, to allow for perMount  
> Handlers via hooks into the VFS, as was suggested in the '[RFC]  
> VFS: FS CoW using redirection' thread.

IMHO a UID mapping is completely the wrong solution for this.  The  
problem is the the subject (the process) and object (the filesystem)  
place different meanings on different UIDs, in other words their UIDs  
are in different namespaces.  The result is that you should tag that  
filesystem (vfsmount, really) with a different namespace tag and fix  
the namespace system to properly handle cross-namespace permissions,  
not forcibly graft on some fragile mapping system.  By using the  
keyring system for foreign-namespace UID permissions the actual  
permissions fall out quite nicely.

Cheers,
Kyle Moffett

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists