[Proftpd-user] problem with proftpd (linux) uploading to anfs volume - proftpd

This is a discussion on [Proftpd-user] problem with proftpd (linux) uploading to anfs volume - proftpd ; I posted a message about this in July, but was getting the list via digest, plus was out on vacation. I'm really interested in finding a solution, so we'll try this again. We have anonymous ftp configured on a linux ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: [Proftpd-user] problem with proftpd (linux) uploading to anfs volume

  1. [Proftpd-user] problem with proftpd (linux) uploading to anfs volume

    I posted a message about this in July, but was getting the list via
    digest, plus was out on vacation. I'm really interested in finding a
    solution, so we'll try this again.

    We have anonymous ftp configured on a linux box (rhel4 and I've tried
    rhel5). It has been working for years with the ftp directory being on
    the local disk. When we moved the ftp dir to an NFS volume, our
    UserOwner and GroupOwner directives stopped working. We're able to
    upload files, but they're not being chowned; that part fails.

    chown(/incoming/blah/filename) as root failed: Operation not permitted

    Export permissions are okay. I'm able to do the chown as root on the
    ftp server (NFS client) via command-line. And, if I change the ftp root
    directory back to the local disk, it works fine too; so it doesn't
    appear to be a problem with the binary or config file.

    Here's a little more detailed debugging:

    proftpd[4375] dispatching CMD command 'STOR configure2' to mod_xfer
    proftpd[4375] ROOT PRIVS at mod_xfer.c:800
    proftpd[4375] ROOT PRIVS: ID switching disabled
    proftpd[4375] PRIVS_RELINQUISH: ID switching disabled
    proftpd[4375] chown(/incoming/blah/filename) as root failed: Operation
    not permitted

    I've tracked it to this in mod_xfer.c:

    PRIVS_ROOT
    if (pr_fsio_chown(xfer_path, session.fsuid, session.fsgid) == -1) {
    iserr++;
    err = errno;
    }
    PRIVS_RELINQUISH

    if (iserr)
    pr_log_pri(PR_LOG_WARNING, "chown(%s) as root failed: %s", xfer_path,
    strerror(err));

    Unfortunately, I don't understand the code in src/fsio.c for
    pr_fsio_chown. It looks like it issues a variable chown command
    depending on the file system. My guess is that it's doing something
    different for NFS; something that isn't working. Where/how to change
    that is the question. Any ideas? Or any other suggestions?

    I had actually given up on Proftp and went shopping for a replacement,
    but the ones I've seen thus far just don't have the feature set for
    uploads. Then again, this just isn't working for me anymore, so...

    Relevant portions of proftpd.conf:
    CapabilitiesEngine on
    CapabilitiesSet +CAP_CHOWN


    User ftp
    Group bin

    UserOwner joeuser
    GroupOwner joegroup
    umask 007





    TJ Saunders replied back in July, asking about NFS permissions and my
    compile settings. Since it works via command-line as root, I think we
    can rule NFS permissions out.

    The one potentially complicating factor is that the ftp server thinks
    there are ACLs on the files/dirs in the ftp area, even though there
    aren't. 'ls' reports a '+', which signifies an ACL. 'getfacl' doesn't
    report anything unusual. And again, command-line chmod works fine.

    Compile-time Settings:
    Version: 1.3.2rc2
    Platform: LINUX
    Built With:
    configure '--prefix=/private/proftp' '--with-modules=mod_ldap'

    CFLAGS: -O2 -Wall
    LDFLAGS: -L$(top_srcdir)/lib
    LIBS: -lcap -lldap -llber -lpam -lsupp -lcrypt

    Files:
    Configuration File:
    /private/proftp/etc/proftpd.conf
    Pid File:
    /private/proftp/var/proftpd.pid
    Scoreboard File:
    /private/proftp/var/proftpd/proftpd.scoreboard

    Features:
    - Autoshadow support
    - Controls support
    + curses support
    - Developer support
    - DSO support
    + IPv6 support
    + Largefile support
    - Lastlog support
    + ncurses support
    - NLS support
    - OpenSSL support
    - POSIX ACL support
    + Shadow file support
    + Sendfile support
    + Trace support

    Tunable Options:
    PR_TUNABLE_BUFFER_SIZE = 1024
    PR_TUNABLE_GLOBBING_MAX = 8
    PR_TUNABLE_HASH_TABLE_SIZE = 40
    PR_TUNABLE_NEW_POOL_SIZE = 512
    PR_TUNABLE_SCOREBOARD_BUFFER_SIZE = 80
    PR_TUNABLE_SCOREBOARD_SCRUB_TIMER = 30
    PR_TUNABLE_SELECT_TIMEOUT = 30
    PR_TUNABLE_TIMEOUTIDENT = 10
    PR_TUNABLE_TIMEOUTIDLE = 600
    PR_TUNABLE_TIMEOUTLINGER = 180
    PR_TUNABLE_TIMEOUTLOGIN = 300
    PR_TUNABLE_TIMEOUTNOXFER = 300
    PR_TUNABLE_TIMEOUTSTALLED = 3600
    PR_TUNABLE_XFER_SCOREBOARD_UPDATES = 10


    thank you

    Tom Lieuallen
    Oregon State University

    -------------------------------------------------------------------------
    This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
    Build the coolest Linux based applications with Moblin SDK & win great prizes
    Grand prize is a trip for two to an Open Source event anywhere in the world
    http://moblin-contest.org/redirect.p...r_id=100&url=/
    _______________________________________________
    ProFTPD Users List
    Unsubscribe problems?
    http://www.proftpd.org/list-unsub.html


  2. Re: [Proftpd-user] problem with proftpd (linux) uploading to a nfsvolume


    > We have anonymous ftp configured on a linux box (rhel4 and I've tried
    > rhel5). It has been working for years with the ftp directory being on
    > the local disk. When we moved the ftp dir to an NFS volume, our
    > UserOwner and GroupOwner directives stopped working. We're able to
    > upload files, but they're not being chowned; that part fails.
    >
    > chown(/incoming/blah/filename) as root failed: Operation not permitted


    > proftpd[4375] ROOT PRIVS: ID switching disabled
    > proftpd[4375] PRIVS_RELINQUISH: ID switching disabled


    This "ID switching disabled" is sign that Linux capabilities are involved;
    the mod_cap module is restricting even what root can do (as is its
    purpose). See:

    http://www.proftpd.org/docs/modules/mod_cap.html

    > uploads. Then again, this just isn't working for me anymore, so...
    >
    > Relevant portions of proftpd.conf:
    > CapabilitiesEngine on


    You might try just turning off mod_cap, just to rule it out completely:

    CapabilitiesEngine off

    Cheers,
    TJ


    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    Axioms in philosophy are not axioms until they are proved upon our pulses:
    we read fine things but never feel them to the full until we have gone
    the same steps as the author.

    John Keats

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~




    -------------------------------------------------------------------------
    This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
    Build the coolest Linux based applications with Moblin SDK & win great prizes
    Grand prize is a trip for two to an Open Source event anywhere in the world
    http://moblin-contest.org/redirect.p...r_id=100&url=/
    _______________________________________________
    ProFTPD Users List
    Unsubscribe problems?
    http://www.proftpd.org/list-unsub.html


  3. Re: [Proftpd-user] problem with proftpd (linux) uploading to a nfsvolume

    First the good news; I have it working again. You can't imagine what a
    relief. :-)

    The solution was a combination of disabling CapabilitiesEngine and
    mucking with ownership and permissions of the uploaded files.

    With the ftp files on the local machine, we had very fine grained
    control over permissions. I could set UserOwner, GroupOwner, and umask
    such that the resulting permissions wouldn't even let the ftp server
    access it. The only caveat was that the directory we're writing to had
    to be writable by either the ftp user or ftp group.
    UserOwner some_other_user
    GroupOwner some_other_group
    umask 007

    However, over NFS we appear to have to set permissions for the uploaded
    file such that the ftp user or group has write access. I need at least
    a umask of 007 and to not override the user or group.

    While this isn't quite as feature-rich, it is something that I can
    definitely live with.

    Thank you TJ for honing in on the problem and getting me 99% the way
    there. :-)

    Tom Lieuallen
    Oregon State University

    TJ Saunders wrote:
    >> We have anonymous ftp configured on a linux box (rhel4 and I've tried
    >> rhel5). It has been working for years with the ftp directory being on
    >> the local disk. When we moved the ftp dir to an NFS volume, our
    >> UserOwner and GroupOwner directives stopped working. We're able to
    >> upload files, but they're not being chowned; that part fails.
    >>
    >> chown(/incoming/blah/filename) as root failed: Operation not permitted

    >
    >> proftpd[4375] ROOT PRIVS: ID switching disabled
    >> proftpd[4375] PRIVS_RELINQUISH: ID switching disabled

    >
    > This "ID switching disabled" is sign that Linux capabilities are involved;
    > the mod_cap module is restricting even what root can do (as is its
    > purpose). See:
    >
    > http://www.proftpd.org/docs/modules/mod_cap.html
    >
    >> uploads. Then again, this just isn't working for me anymore, so...
    >>
    >> Relevant portions of proftpd.conf:
    >> CapabilitiesEngine on

    >
    > You might try just turning off mod_cap, just to rule it out completely:
    >
    > CapabilitiesEngine off
    >
    > Cheers,
    > TJ


    -------------------------------------------------------------------------
    This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
    Build the coolest Linux based applications with Moblin SDK & win great prizes
    Grand prize is a trip for two to an Open Source event anywhere in the world
    http://moblin-contest.org/redirect.p...r_id=100&url=/
    _______________________________________________
    ProFTPD Users List
    Unsubscribe problems?
    http://www.proftpd.org/list-unsub.html


+ Reply to Thread