linux-ext4 - Re: [PATCH,RFC] Adding quotacheck functionality to e2fsck

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: <20100330124214.GA3424@quack.suse.cz>
Date:	Tue, 30 Mar 2010 14:42:14 +0200
From:	Jan Kara <jack@...e.cz>
To:	Dmitry Monakhov <dmonakhov@...nvz.org>
Cc:	Jan Kara <jack@...e.cz>, tytso@....edu, linux-ext4@...r.kernel.org
Subject: Re: [PATCH,RFC] Adding quotacheck functionality to e2fsck

On Tue 30-03-10 09:26:52, Dmitry Monakhov wrote:
> Jan Kara <jack@...e.cz> writes:
> > On Fri 26-03-10 09:38:56, tytso@....edu wrote:
> >> On Fri, Mar 26, 2010 at 11:42:05AM +0100, Jan Kara wrote:
> >> > > There may also be other programs that depend on the existence of
> >> > > aquota.user, and may be reading and writing them in various random
> >> > > ways, and there is the question of how do we provide compatibility
> >> > > with these other programs, some of which may not be within quotatools,
> >> > > but in various magic virtualization or container or cluster management
> >> > > systems....
> >> >   Yeah, this is possible, although I'm not aware of any such program -
> >> 
> >> Actually, Google's cluster management system is accessing/modifying
> >> aquota.group file directly before and after quota is enabled.  This
> >> may change in the future, but it's one more point of compatibility.
> >   I see. Thanks for info.
> >
> >> >   Yeah, I believe that support for the oldest quota format can be phased
> >> > out - the new format is around for something like 10 years and it had
> >> > it's problems at that time already. I guess I'll add a warning to the
> >> > next release of quota-tools to the people still using it.
> >> 
> >> And if we transition to using quotactl calls to access and read the
> >> information in the quota files, then the actual format of the quota
> >> file won't matter any more, right?
> >   Yes, hopefully.
> >
> >> Stupid question --- how does repquota work on OCFS2?  I don't see any
> >> quotactl subcommands that would appear to return the functionality
> >> needed by repquota --- unless you just assume that the only uid/gid's
> >> in use are in /etc/passwd and /etc/group, and just call quotactl for
> >> each uid/gid in the system passwd and group files.
> >   Currently it does not work at all. I didn't get to writing it when
> > writing original quota support for OCFS2 because the inferface won't be
> > completely trivial and it would be complicated for OCFS2 to expose the
> > file directly. Probably the interface will have to be something like
> > readdir but then you have to have some "handles" and state associated
> > with them and it gets complicated. Maybe we could make our life simpler
> > by returning an read-only unseekable fd from repquota quotactl and reading
> > from it would pass quota structures. But I haven't thought too much about
> > it.
> Ok. i hope finally we will end up with something like this.
> Before introducing this interface it is reasonable to redesign
> dquot structures itself because they aren't linked together
> so it is not easy to iterate it without probing each id in a loop.
  Well, the quotactl call would scan the quota file on disk anyway because
all the dquot structures needn't be loaded in memory. So linking structures
in memory will not help.

									Honza
-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html