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 14:52:10 +0100
From:	Matthias Koenig <mkoenig@...e.de>
To:	Theodore Tso <tytso@....edu>
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

Theodore Tso <tytso@....edu> writes:

> On Mon, Jan 28, 2008 at 04:26:53PM +0100, Matthias Koenig wrote:
>> > Patch6:         e2fsprogs-mdraid.patch
>> >
>> > This apparently adds a new environment variable,
>> > BLKID_SKIP_CHECK_MDRAID, which forces blkid to not detect mdraid
>> > devices.  I'm not sure why.
>> 
>> Workaround for people having stale RAID signature on their disk:
>> https://bugzilla.novell.com/show_bug.cgi?id=100530
>
> Hmm... there's got to be a better way around this.
>
> I'm not authorized to look at that BZ entry.  Is there any way you can
> make my "tytso" account have access to any e2fsprogs related BZ
> entries?  Thanks!

Still waiting for the person with privileges to do this.
In the meanwhile I will add you to the CC list of this bug, then you
should also be able to access the bug.

>
>> > Patch12:        e2fsprogs-mkinstalldirs.patch
>> >
>> > Why?
>> 
>> Is needed since we recreate the auto* files.
>> But I agree that this patch should better set
>> MKINSTALLDIRS = @MKDIR_P@
>> not to literal "mkdir -p". The @MKINSTALLDIRS@ seems to be
>> obsolete in newer gettext (which seems to pull this in).
>
> 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.

>
>> > Patch22:        e2fsprogs-1.40.4-uuidd_pid_path.patch
>> >
>> > The problem with this patch is that /var/run is cleared via rm -rf, so
>> > it is highly problamtic to put the scratch directory for uuidd in
>> > /var/run.
>> 
>> Are you really sure? My interpretation of FHS is, that files under
>> /var/run/ have to be cleared or truncated, but the subdirectories do not
>> get deleted.
>
> 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). The only problem with uuidd is that it is designed to run upon
demand. But on the other side it is also not strictly necessary to run
uuidd to create UUIDs, only if you have special requirements on the
UUIDs. So I don't see a problem if uuidd could not be started for the
creation of UUIDs *generally* and if people wanting really unique
time-based UUIDs are required to run the init script first upon boot, 
which guarantees the existence of the /var/run/uuidd directory.
Any problems with this approach?

> Please let me know when you have a newer OpenSUSE factory RPM ready
> for use, and I'll take a look at the remaining patches and see which
> ones are ready for merging upstream. 

Yes, will do so. I am currently still looking through all the patches
where they come from and why they are needed. Will probably submit
a new package today.

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

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