lkml.org 
[lkml]   [2011]   [Oct]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: A Plumber’s Wish List for Linux
    On Fri, Oct 7, 2011 at 12:12, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
    >> * (ioctl based?) interface to query and modify the label of a mounted
    >> FAT volume:
    >
    > Seems sensible - or it could go in sysfs ?

    That would mean to export superblocks in /sys, which isn't namespaced,
    and which might create issues by making information globally available
    which probably shouldn't?

    >> A FAT labels is implemented as a hidden directory entry in the file
    >> system which need to be renamed when changing the file system label,
    >
    > That would be ugly - it works for FAT as you can create an imaginary name
    > which is not possible on the fs, but that isn't true for say ext4. Sysfs
    > sounds the logic way, it means adding chunks of code to various file
    > systems.

    What do you mean would be ugly?

    >> * expose CAP_LAST_CAP somehow in the running kernel at runtime:
    >> Userspace needs to know the highest valid capability of the running
    >> kernel, which right now cannot reliably be retrieved from header files
    >> only. The fact that this value cannot be detected properly right now
    >> creates various problems for libraries compiled on newer header files
    >> which are run on older kernels. They assume capabilities are available
    >> which actually aren’t. Specifically, libcap-ng claims that all running
    >> processes retain the higher capabilities in this case due to the
    >> “inverted” semantics of CapBnd in /proc/$PID/status.
    >
    > You can probably deduce this by poking around but to me it seems like a
    > very sensible idea.
    >
    >> * allow changing argv[] of a process without mucking with environ[]:
    >> Something like setproctitle() or a prctl() would be ideal. Of course it
    >> is questionable if services like sendmail make use of this, but otoh for
    >> services which fork but do not immediately exec() another binary being
    >> able to rename this child processes in ps is of importance.
    >
    > Yes, its a real valuable tool for r00tkits, worms and general purpose
    > deception.

    They can do that already today. The code to do that just looks really
    ugly. So the r00tkits could have nicer looking code. :)

    Thanks,
    Kay
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2011-10-07 12:31    [W:3.169 / U:0.088 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site