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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151125175153.GA30335@fieldses.org>
Date:	Wed, 25 Nov 2015 12:51:53 -0500
From:	bfields@...ldses.org (J. Bruce Fields)
To:	David Howells <dhowells@...hat.com>
Cc:	Martin Steigerwald <martin@...htvoll.de>, arnd@...db.de,
	linux-afs@...r.kernel.org, linux-nfs@...r.kernel.org,
	linux-cifs@...r.kernel.org, samba-technical@...ts.samba.org,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-ext4@...r.kernel.org
Subject: Re: [RFC][PATCH 00/12] Enhanced file stat system call

On Fri, Nov 20, 2015 at 04:28:35PM +0000, David Howells wrote:
> Martin Steigerwald <martin@...htvoll.de> wrote:
> 
> > Any plans to add limitations of filesystem to the call like maximum file
> > size?  I know its mostly relevant for just for FAT32, but on any account
> > rather than trying to write 4 GiB and then file, it would be good to at some
> > time get a dialog at the beginning of the copy.
> 
> Adding filesystem limits can be done.  I got a shopping list of things people
> wanted a while back and I've worked off of that list.  I can add other things
> - that's on of the reasons I left room for expansion.

I ran across systemd/src/basic/path-util.c:fd_is_mount_point() the other
day, and the contortions it goes through made me wonder if we should
also add mnt_id and/or an is_mountpoint boolean--it's annoying to have
to do name_to_handle_at() (not supported on all filesystems) just to get
mnt_id.

(Looking at it now I see it falls back on reading mount id from
/proc/self/fdinfo/<fd>.  Maybe that's good enough.  May depend on
whether there's a potential user that doesn't want to assume access to
/proc?)

--b.
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ