linux-kernel - Re: [PATCH] VFS: new fgetattr() file operation

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] [day] [month] [year] [list]

Message-Id: <E1IlLZi-0007Iv-00@dorka.pomaz.szeredi.hu>
Date:	Fri, 26 Oct 2007 11:33:54 +0200
From:	Miklos Szeredi <miklos@...redi.hu>
To:	dgc@....com
CC:	staubach@...hat.com, akpm@...ux-foundation.org, hch@...radead.org,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH] VFS: new fgetattr() file operation

> On Fri, Oct 26, 2007 at 01:10:14AM +0200, Miklos Szeredi wrote:
> > > On Wed, Oct 24, 2007 at 05:27:04PM +0200, Miklos Szeredi wrote:
> > > > > >> Wouldn't you be better off by attempting to implement an "open
> > > > > >> by ino" operation and an operation to get the generation count
> > > > > >> for the file and then modifying the network protocol of interest
> > > > > >> to use these as identifiers for the file to be manipulated?
> > > > > >>     
> > > > > >
> > > > > > You mean an "open by inode" on the userspace API?  My guess, it
> > > > > > wouldn't get very far.
> > > > > 
> > > > > This isn't a new idea and has been implemented on a variety of
> > > > > different systems.
> > > > 
> > > > Like?
> > > 
> > > XFS.
> > > 
> > > 'man open_by_handle'
> > 
> > Doesn't seem widely used, with 600 something google hits.
> 
> from the man page:
> 
> "They are intended  for  use  by a limited set of system utilities such
> as backup programs."
> 
> It also gets used by HSMs and so it is current, tested and is not
> going away....

Sure.

> > And in this
> > old thread Linus is not entirely enthusiastic about the concept:
> > 
> >   http://lkml.org/lkml/1999/1/11/244
> 
> That was "open by inode number", AFAICT. A handle is an opaque
> blob that can be an arbitrary length defined by the filesystem.
> You have to convert a fd or path to a handle first before you can
> use it later, so any filesystem can implement it...
> 
> i.e. it is exactly what this (unanswered) post suggested:
> 
> http://lkml.org/lkml/1999/1/13/186

Well, yeah, if a filesystem doesn't have a global index, the whole
path could just be stuffed into the handle.

But there's not much point in that, is there?  And because the
interface bypasses normal access checking on parent directories, it
has security implications, making it not generally useful.

Specifically, it is not useful for the "unprivileged file server" case
that Peter was suggesting.

Miklos
-
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/