Le 30/01/2026 à 22:35, aitor a écrit :
> In order to by-pass the disk cache and force a fresh scan of the
> hardware you need to modify your blkid
> initialization:
>
>   if( blkid_get_cache(&cache, 0) ) gotocache_error;
>
> with this one:
>
>   if( blkid_get_cache(&cache, "/dev/null") ) gotocache_error;
>   blkid_probe_all(cache);   // Force a refresh of all devices
>
>
> Even though, the use of blkid_put_cache() is still necessary
> because libblkid uses a ‘Reference Counting’ style
> naming convention to manage the lifecycle of a struct, where
> every*get* has a*put*, in the same way that in
> Glib's GObject every g_object_ref() has a g_object_unref(). The former
> increments the usage of the object, and
> the latter decrements it releasing the object. When the count reaches
> zero, the object is deallocated. By way
> of clarification, to take the ownership of an object involves taking
> the responsibility for destroying the object.
>
> The blkid initialization in qmount allocates dynamic memory in the
> heap to manage the blkid_cache structure,
> even if you have configured the cache so that it does not read or
> write to the disk (by forcing fresh hardware
> probing with "/dev/null"). However, there is no blkid_put_cache() as
> it ought to be according to the*Get/Put* convention. While this is not
> fatal for a short run, if you use qmount in a script that processes
> many disks,
> the memory leak will grow.
>
> As for the linux capabilities, if there is a code error or buffer
> overflow before the program terminates, an
> attacker could exploit that vulnerability while the process still has
> CAP_SYS_ADMIN. It is not about what happens
> when qmount terminates, but rather what could go wrong while qmount is
> still running.

    I'll re-introduce the blkid_put_cache() I have in another
program but I have removed in this one because of its priviledges,
without knowing about this counting. But I don't think
that blkid_probe_all(cache) is needed at all. I think this call is
needed by programs which actually modify the cache, like udev or vdev,
but it isn't the case of qmount. This call is expensive: it reads all
the partition tables and the filesystems' header blocks, and for no
reason here. I think only device managers like udev and vdev need to do
that.

    For what concerns installation with file-capabilities,

sudo setcap cap_sys_admin,cap_dac_override,cap_chown+p
$(INSTALL_EXEC)/$(PGNAME)

    IIUC it sets some bits in the file metadata which are invisible to
ls. Much like POSIX ACL. I don't like that metadata are invisible to ls;
but security can be achieved from within the program: the program could
set the capabilities at its very beginning and then change immediately
its uid to the real uid befaore doing anything else. I imagine
/bin/mount does this because it has no capability at all but it has the
suid bit.

    The choice might be given to the admin to install qmount with
file-capabilities or suid-bit.

    Introducing capabilities is going to take me some time because my
laptop is still running Daedalus and apt-get fails to install
libcap-dev. If someone has the package for Daedalus/amd64, please send
it to me. I can't upgrade to Excalibur for several reasons, but need to
install it from scratch.

--     Didier