On 04/10/2014 10:37 PM, Andy Lutomirski wrote:
It occurs to me that, before going nuts with these kinds of flags, it
may pay to just try to fix the /proc/self/fd issue for real -- we
could just make open("/proc/self/fd/3", O_RDWR) fail if fd 3 is
read-only. That may be enough for the file seali
Hi
On Tue, Apr 22, 2014 at 2:44 PM, Florian Weimer wrote:
> I didn't find that very convincing. But in v2, seals are monotonic, so
> checking them should be reliable enough.
Ok.
> What happens when you create a loop device on a write-sealed descriptor?
Any write-back to the loop-device will f
On 04/22/2014 01:55 PM, David Herrmann wrote:
Hi
On Tue, Apr 22, 2014 at 11:10 AM, Florian Weimer wrote:
Ah. What do you recommend for recipient to recognize such descriptors?
Would they just try to seal them and reject them if this fails?
This highly depends on your use-case. Please see th
Hi
On Tue, Apr 22, 2014 at 11:10 AM, Florian Weimer wrote:
> Ah. What do you recommend for recipient to recognize such descriptors?
> Would they just try to seal them and reject them if this fails?
This highly depends on your use-case. Please see the initial email in
this thread. It describes 2
On 04/09/2014 11:31 PM, David Herrmann wrote:
On Tue, Apr 8, 2014 at 3:00 PM, Florian Weimer wrote:
How do you keep these promises on network and FUSE file systems?
I don't. This is shmem only.
Ah. What do you recommend for recipient to recognize such descriptors?
Would they just try to
On Thu 2014-04-10 13:37:26, Andy Lutomirski wrote:
> On Thu, Apr 10, 2014 at 1:32 PM, Theodore Ts'o wrote:
> > On Thu, Apr 10, 2014 at 12:14:27PM -0700, Andy Lutomirski wrote:
> >>
> >> This is the second time in a week that someone has asked for a way to
> >> have a struct file (or struct inode o
On Thu, Apr 10, 2014 at 4:16 PM, David Herrmann wrote:
> Hi
>
> On Fri, Apr 11, 2014 at 1:05 AM, Andy Lutomirski wrote:
>> /proc/pid/fd is a really weird corner case in which the mode of an
>> inode that doesn't have a name matters. I suspect that almost no one
>> will ever want to open one of t
Hi
On Fri, Apr 11, 2014 at 1:05 AM, Andy Lutomirski wrote:
> /proc/pid/fd is a really weird corner case in which the mode of an
> inode that doesn't have a name matters. I suspect that almost no one
> will ever want to open one of these things out of /proc/self/fd, and
> those who do should be m
On Thu, Apr 10, 2014 at 3:57 PM, David Herrmann wrote:
> Hi
>
> On Thu, Apr 10, 2014 at 11:16 PM, Andy Lutomirski wrote:
>> Would it make sense for the initial mode on a memfd inode to be 000?
>> Anyone who finds this to be problematic could use fchmod to fix it.
>
> memfd_create() should be subj
Hi
On Thu, Apr 10, 2014 at 11:16 PM, Andy Lutomirski wrote:
> Would it make sense for the initial mode on a memfd inode to be 000?
> Anyone who finds this to be problematic could use fchmod to fix it.
memfd_create() should be subject to umask() just like anything else.
That should solve any poss
On Thu, Apr 10, 2014 at 1:49 PM, David Herrmann wrote:
> Hi
>
> On Thu, Apr 10, 2014 at 10:37 PM, Andy Lutomirski wrote:
>> It occurs to me that, before going nuts with these kinds of flags, it
>> may pay to just try to fix the /proc/self/fd issue for real -- we
>> could just make open("/proc/sel
Hi
On Thu, Apr 10, 2014 at 10:37 PM, Andy Lutomirski wrote:
> It occurs to me that, before going nuts with these kinds of flags, it
> may pay to just try to fix the /proc/self/fd issue for real -- we
> could just make open("/proc/self/fd/3", O_RDWR) fail if fd 3 is
> read-only. That may be enoug
On Thu, Apr 10, 2014 at 1:32 PM, Theodore Ts'o wrote:
> On Thu, Apr 10, 2014 at 12:14:27PM -0700, Andy Lutomirski wrote:
>>
>> This is the second time in a week that someone has asked for a way to
>> have a struct file (or struct inode or whatever) that can't be reopened
>> through /proc/pid/fd.
On Thu, Apr 10, 2014 at 12:14:27PM -0700, Andy Lutomirski wrote:
>
> This is the second time in a week that someone has asked for a way to
> have a struct file (or struct inode or whatever) that can't be reopened
> through /proc/pid/fd. This should be quite easy to implement as a
> separate featu
On Thu, Apr 10, 2014 at 3:15 PM, Andy Lutomirski
wrote:
COW links can do this already, I think. Of course, you'll have to
use a
filesystem that supports them.
COW is nice if the filesystem supports them, but my userspace code
needs to be filesystem agnostic. Because of that, the design
On 04/08/2014 06:00 AM, Florian Weimer wrote:
> On 03/19/2014 08:06 PM, David Herrmann wrote:
>
>> Unlike existing techniques that provide similar protection, sealing
>> allows
>> file-sharing without any trust-relationship. This is enforced by
>> rejecting seal
>> modifications if you don't own a
On 04/10/2014 07:45 AM, Colin Walters wrote:
> On Thu, Mar 20, 2014 at 11:32 AM, ty...@mit.edu wrote:
>>
>> Looking at your patches, and what files you are modifying, you are
>> enforcing this in the low-level file system.
>
> I would love for this to be implemented in the filesystem level as
> we
On 03/20/2014 09:38 AM, ty...@mit.edu wrote:
> On Thu, Mar 20, 2014 at 04:48:30PM +0100, David Herrmann wrote:
>> On Thu, Mar 20, 2014 at 4:32 PM, wrote:
>>> Why not make sealing an attribute of the "struct file", and enforce it
>>> at the VFS layer? That way all file system objects would have a
On Thu, Mar 20, 2014 at 11:32 AM, ty...@mit.edu wrote:
Looking at your patches, and what files you are modifying, you are
enforcing this in the low-level file system.
I would love for this to be implemented in the filesystem level as
well. Something like the ext4 immutable bit, but with the
Hi
On Tue, Apr 8, 2014 at 3:00 PM, Florian Weimer wrote:
> How do you keep these promises on network and FUSE file systems?
I don't. This is shmem only.
Thanks
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
On 03/19/2014 08:06 PM, David Herrmann wrote:
Unlike existing techniques that provide similar protection, sealing allows
file-sharing without any trust-relationship. This is enforced by rejecting seal
modifications if you don't own an exclusive reference to the given file. So if
you own a file-d
On Thu, Mar 20, 2014 at 04:48:30PM +0100, David Herrmann wrote:
> On Thu, Mar 20, 2014 at 4:32 PM, wrote:
> > Why not make sealing an attribute of the "struct file", and enforce it
> > at the VFS layer? That way all file system objects would have access
> > to sealing interface, and for memfd_sh
Hi
On Thu, Mar 20, 2014 at 4:32 PM, wrote:
> Why not make sealing an attribute of the "struct file", and enforce it
> at the VFS layer? That way all file system objects would have access
> to sealing interface, and for memfd_shmem, you can't get another
> struct file pointing at the object, the
On Wed, Mar 19, 2014 at 08:06:45PM +0100, David Herrmann wrote:
>
> This series introduces the concept of "file sealing". Sealing a file restricts
> the set of allowed operations on the file in question. Multiple seals are
> defined and each seal will cause a different set of operations to return
On Thu, 20 Mar 2014 16:12:54 +0100
David Herrmann wrote:
> Hi
>
> On Thu, Mar 20, 2014 at 3:41 PM, One Thousand Gnomes
> wrote:
> > I think you want two things at minimum
> >
> > owner to seal
> > root can always override
>
> Why should root be allowed to override?
Because root can already ov
Hi
On Thu, Mar 20, 2014 at 3:41 PM, One Thousand Gnomes
wrote:
> I think you want two things at minimum
>
> owner to seal
> root can always override
Why should root be allowed to override?
> I would query the name too. Right now your assumption is 'shmem only' but
> that might change with other
> My first idea was to add MFD_ALLOW_SEALING as memfd_create() flag,
> which enables the sealing-API for that file. Then I looked at POSIX
This actually seems the most sensible to me. The reason being that if I
have some existing used object there is no way on earth I can be sure who
has existing
Hi
On Thu, Mar 20, 2014 at 4:49 AM, Linus Torvalds
wrote:
> Is there really any use-case where the sealer isn't also the same
> thing that *created* the file in the first place? Because I would be a
> ton happier with the notion that you can only seal things that you
> yourself created. At that p
On Wed, Mar 19, 2014 at 12:06 PM, David Herrmann wrote:
>
> Unlike existing techniques that provide similar protection, sealing allows
> file-sharing without any trust-relationship. This is enforced by rejecting
> seal
> modifications if you don't own an exclusive reference to the given file.
I
On Wed, Mar 19, 2014 at 08:06:45PM +0100, David Herrmann wrote:
> Hi
>
> This series introduces the concept of "file sealing". Sealing a file restricts
> the set of allowed operations on the file in question. Multiple seals are
> defined and each seal will cause a different set of operations to re
Hi
This series introduces the concept of "file sealing". Sealing a file restricts
the set of allowed operations on the file in question. Multiple seals are
defined and each seal will cause a different set of operations to return EPERM
if it is set. The following seals are introduced:
* SEAL_SHRI
31 matches
Mail list logo
