Menu

#237 USERID and APACHEID Conflicts

XOOPS_2.x
open
nobody
5
2012-09-25
2006-09-27
XoopsGold
No

Hallo Skalpa!

I address to you as I know that you are on the final
versions before release.

During the uploads with xcGal in to user albums, I
noticed that when a user creates an album the first
time, the directory is created under the general
ApacheID of the server. However, all the Xoops php
scripts have the AccountID ownership.

The directories created also has the AccountID
ownership. The data or files, gif/jpg stored in those
directories have the ApacheID ownership!

This is really a conflict.

The scripts are owned by the account, they create
apacheID in ownerships!

This is also a chaos!!!

Hence if there is a general class that the Xoops main
CORE calls for thos functions and does not allow any
other module to do other than this, would be the best
solution.

I suggest that:

The scripts should check the Ownership of the scripts
itself and then create the respective ownerships of
sub-directores if possible.

Discussion

  • Skalpa Keo

    Skalpa Keo - 2006-10-29

    Logged In: YES
    user_id=882380

    Hi,

    Well, this is server related and there's nothing we can do about this actually. There
    are several solutions that already exist and fix that, like mod_suexec or suphp on
    apache (and if I'm not mistaking, IIS also allows to have the accountID be the same as
    the serverID ), but the decision to use one of them depends on your hosting company.

    In fact releasing XOOPS with some folders already here even if they are empty (like
    templates_c) is the only solution we had to make sure the folders exists and have the
    correct UID whatever configuration people use.

    The only other solution we have, would be to make XOOPS connect to the server it is on
    using FTP, and create folders that way, but it's not easy or convenient: the
    only "easy" way to do something like this would be to store the FTP user/pass somewhere
    (like mainfile.php), but it's a real issue security speaking, and something I am
    against. To do it well, we would then have to ask the pwd each time, or at least
    encrypt it and just ask the key needed to decrypt when it's needed, and it's not
    something that would only take 5 mins.

    Anyway, I'm setting this to "accepted", coz having somebody to code such a system for
    us would be nice :-)

    thanks

    skalpa.>

     
  • XoopsGold

    XoopsGold - 2006-10-29

    Logged In: YES
    user_id=1329834

    Hallo Skalpa!

    Like always, I like your answers! Thanks...

    I use my own server (Debian) und have no shared account. So
    Hosting company does not come into picture. I can actually
    do what I want in view of Owner/UserIDs.

    However this does not help. There are several reason for
    this as mentioned below:

    The scripts run under lets say a User: UserID (or AccountID
    for that fact) and the script creates directories with User:
    NobodyID!

    The reason is that the NobodyID has been created due to the
    Apache Server apache.conf having the minimum rights by the
    scripts on the server. UserID has more rights, possibily.

    Here ist a concrete example of how and exactly where the
    comfilct occurs:

    All the php scripts are with UserID, that a User used during
    the installation. Alle the directories are also having the
    UserID as well.

    A User makes an Album. This will create a directory with the
    Albumname having the NobodyID.

    When the xcGal tries to Upload a photo into the directory,
    the scripts of xcGal trying to Upload are UserID refusing to
    allow the upload!

    This has happened several times also with other scripts
    havng UserID and the dir having NobodyID.

    Thats the conflict.

    Is it possible that the Xoops scripts calls the OwnerID of
    the scripts, inherits them and then creates OwnerID of all
    uploads, etc...

     
  • XoopsGold

    XoopsGold - 2006-10-29

    Logged In: YES
    user_id=1329834

    Hallo Skalpa!

    Like always, I like your answers! Thanks...

    I use my own server (Debian) und have no shared account. So
    Hosting company does not come into picture. I can actually
    do what I want in view of Owner/UserIDs.

    However this does not help. There are several reason for
    this as mentioned below:

    The scripts run under lets say a User: UserID (or AccountID
    for that fact) and the script creates directories with User:
    NobodyID!

    The reason is that the NobodyID has been created due to the
    Apache Server apache.conf having the minimum rights by the
    scripts on the server. UserID has more rights, possibily.

    Here ist a concrete example of how and exactly where the
    comfilct occurs:

    All the php scripts are with UserID, that a User used during
    the installation. Alle the directories are also having the
    UserID as well.

    A User makes an Album. This will create a directory with the
    Albumname having the NobodyID.

    When the xcGal tries to Upload a photo into the directory,
    the scripts of xcGal trying to Upload are UserID refusing to
    allow the upload!

    This has happened several times also with other scripts
    havng UserID and the dir having NobodyID.

    Thats the conflict.

    Is it possible that the Xoops scripts calls the OwnerID of
    the scripts, inherits them and then creates OwnerID of all
    uploads, etc...

     
  • XoopsGold

    XoopsGold - 2006-10-29

    Logged In: YES
    user_id=1329834

    Hallo Skalpa!

    You say:

    The only other solution we have, would be to make XOOPS connect
    to the server it is on
    using FTP, and create folders that way,


    I mean that the files are created with different IDs and not
    folders.

    Which means that the files responsible for creation have
    different IDs that the End products i.e. files created by
    them UserID >> NobodyID!

     

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.