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
On Jun 17, 2014 2:48 AM, "Florian Weimer" wrote:
>
> 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) fai
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.
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 tr
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
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
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 pos
Colin Walters wrote:
> 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 filesyste
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 enou
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
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 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
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
On Thu, Mar 20, 2014 at 11:32 AM, tytso at 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 wit
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
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 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, tytso at 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
>
On 03/20/2014 09:38 AM, tytso at 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 hav
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
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
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
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
On Thu, 20 Mar 2014 11:32:51 -0400
tytso at mit.edu wrote:
> 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
>
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
> 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
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
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
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
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
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
34 matches
Mail list logo
