linux-ext4 - Re: Integrating patches in SLES10 e2fsprogs

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

Date:	Tue, 29 Jan 2008 09:35:37 -0500
From:	Theodore Tso <tytso@....EDU>
To:	Matthias Koenig <mkoenig@...e.de>
Cc:	linux-ext4@...r.kernel.org, hvogel@...e.de,
	Girish Shilamkar <Girish.Shilamkar@....COM>,
	Eric Sandeen <esandeen@...hat.com>
Subject: Re: Integrating patches in SLES10 e2fsprogs

On Tue, Jan 29, 2008 at 02:52:10PM +0100, Matthias Koenig wrote:
> > Are you running aclocal?  That may be causing the issues since I think
> > that may be causing it to ignore the autoconf macros I've established
> > in the top-level aclocal.m4 file.
> 
> Yes, someone here fixed the german po file (I already sent it to
> translation project). So we have to rerun the
> gettext related part, which results in the requirement to rerun aclocal.

Hmm?  You should be able to rebuild the .gmo file without needing to
re-run aclocal.  I do it all the time.  :-)

> > The problem is that the FHS does not guarantee that the subdirectories
> > stick around, and a number of distro's are using mounting tmpfs for
> > /var/run.  Makes sense, it can significantly speed up operations ---
> > but upon reboot, everything in /var/run is *gone*.
> 
> I see, then there is a problem of course. This is not the way it is
> done in Suse, so I did not see this problem.
> But, shouldn't the daemon then have an rc init script which checks for
> the needed subdirectory in /var/run and creates this if necessary?  If I
> look into /var/run I see a lot of daemons running with their own UID/GID
> and having their own directory. In this case there must be a mechanism
> to guarantee the existence of this directory, which would obviously be
> done in the init script (not sure if any init scripts currently do this
> in Suse).

Well, it either needs to be done in the init script or the daemons run
with root privs, create the directory, and then drop root privs.  So
yes, there are alternatives.  (a) Yet Another init script, (b) setuid
root, with a hard-coded user name that has to be looked up via
getpwent() and configured into /etc/passwd or the LDAP server, (c)
just put the darned directory in /var/lib.

It's all about tradeoffs, and for me, (c) was the easist, especially
since /var/lib/libuuid/clock.txt needs to be persistent across boots
anyway, and so needs to be in /var/lib instead of /var/run.  So yes, I
could have created some machinery to make sure /var/run/uuidd is
always present, but why not just reuse the already existing
/var/lib/libuuid directory, which has the correct ownership and which
has to be in /var/lib anyway?

> > and I still haven't figured out how to easily build my own
> > custom kernel RPM's on OpenSUSE, but it's quite nice.
> 
> unfortunately we don't have make-kpkg.

Yeah, and the RPM macros for generating kernel are incredibly twisted.
At least they were for RHEL4, when I was figuring out how to generate
a real-time kernel rpm.  Serious temptations to gouge out my eyeballs
with a spoon by the time I was done....

       	     					- Ted
-
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