FAQ
Hi all,
I've been trying to figure out a way that I can have my users allowed to
login to the server (HP-UX) with their own account and run a shell script
that's owned my me ... but I don't want them to be able to see the password.
I had no luck just granting them execute on the shell script, they had to
have read priviledges in order to execute it apparently.
Any suggestions??

Thank you!
-FS

Don’t just search. Find. Check out the new MSN Search!
http://search.msn.click-url.com/go/onm00200636ave/direct/01/

Search Discussions

  • David Sharples at Feb 16, 2006 at 6:35 pm
    sudo?

    you shouldnt need to give them read access to execute a script though -
    something wrong there maybe

    On 2/16/06, Fred Smith wrote:
    I've been trying to figure out a way that I can have my users allowed to
    login to the server (HP-UX) with their own account and run a shell script
    that's owned my me ... but I don't want them to be able to see the password.
    I had no luck just granting them execute on the shell script, they had to
    have read priviledges in order to execute it apparently.
    Any suggestions??
  • Radoulov, Dimitre at Feb 16, 2006 at 7:25 pm
    you shouldnt need to give them read access to execute a script though -
    How?

    Regards,
    Dimitre
  • David Sharples at Feb 16, 2006 at 7:39 pm
    apologies, just tested it - I'm wrong as usual :-)
    On 2/16/06, Radoulov, Dimitre wrote:

    you shouldnt need to give them read access to execute a script though -
    How?
    --
    http://www.freelists.org/webpage/oracle-l
  • Jonathan Knight at Feb 16, 2006 at 7:37 pm
    I've used SQL*Loader for years to load various data.

    My current project requires a largish daily update to
    a database table. Is there any way to do this with
    SQL*Loader? If not, I'm looking at loading to a
    temporary table and kicking off a PL/SQL job to update
    the affected records.

    Thanks,
    Jon

    Do You Yahoo!?
    Tired of spam? Yahoo! Mail has the best spam protection around
    http://mail.yahoo.com

    --
    http://www.freelists.org/webpage/oracle-l
  • David Sharples at Feb 16, 2006 at 7:41 pm
    define large and are they simple inserts or updates?

    using external tables and simple sql might be worth looking at
    On 2/16/06, Jonathan Knight wrote:

    My current project requires a largish daily update to
    a database table. Is there any way to do this with
    SQL*Loader? If not, I'm looking at loading to a
    temporary table and kicking off a PL/SQL job to update
    the affected records.
    --
    http://www.freelists.org/webpage/oracle-l
  • Stephane Faroult at Feb 16, 2006 at 10:47 pm
    ... To be more precise external table + MERGE.

    Stéphane Faroult

    David Sharples wrote:
    define large and are they simple inserts or updates?

    using external tables and simple sql might be worth looking at


    On 2/16/06, *Jonathan Knight*
    wrote:
    My current project requires a largish daily update to
    a database table. Is there any way to do this with
    SQL*Loader? If not, I'm looking at loading to a
    temporary table and kicking off a PL/SQL job to update
    the affected records.
    --
    http://www.freelists.org/webpage/oracle-l
  • Jonathan Knight at Feb 17, 2006 at 6:16 pm
    I just have some test files about 1GB in size and I
    don't yet know the total number of records I'll be
    receiving. The process will insert and update and
    existing table.

    The External + merge looks promising. Thanks!

    Jon Knight

    Stephane Faroult wrote:
    ... To be more precise external table + MERGE.

    Stéphane Faroult

    David Sharples wrote:
    define large and are they simple inserts or updates?
    using external tables and simple sql might be
    worth looking at

    On 2/16/06, *Jonathan Knight*
    wrote:
    My current project requires a largish daily update to
    a database table. Is there any way to do this with
    SQL*Loader? If not, I'm looking at loading to a
    temporary table and kicking off a PL/SQL job to update
    the affected records.

    --
    http://www.freelists.org/webpage/oracle-l

    Do You Yahoo!?
    Tired of spam? Yahoo! Mail has the best spam protection around
    http://mail.yahoo.com

    --
    http://www.freelists.org/webpage/oracle-l
  • Dennis Williams at Feb 16, 2006 at 7:01 pm
    Fred,

    >
    login to the server (HP-UX) with their own account and run a shell script
    that's owned my me ... but I don't want them to be able to see the
    password.
    If you are saying you want them to run a shell script that has an embedded
    password, I would say that isn't very secure anyway. Why not have the script
    make a call a program that retrieves the password? Goodle for the keywords
    sqlplus hide password and you will find several examples.

    Dennis Williams
  • Allen, Brandon at Feb 16, 2006 at 7:36 pm
    Yes, you must have read permission also to execute a script:

    ## As user1 (file owner):
    /mnt1/oracle ->cat test.ksh
    date

    /mnt1/oracle:$ ll test.ksh
    -rwx-----x 1 oracle dba 10 Feb 16 11:27 test.ksh

    ## As user2:
    /mnt1/oracle:$ test.ksh
    test.ksh: Cannot find or open the file.

    ## As user1 (file owner):
    /mnt1/oracle ->chmod 705 test.ksh
    /mnt1/oracle ->ll test.ksh
    -rwx---r-x 1 oracle dba 5 Feb 16 11:32 test.ksh

    ## As user2:
    /mnt1/oracle:$ ./test.ksh
    Thu Feb 16 11:33:31 PST 2006

    -----Original Message-----
    From: oracle-l-bounce_at_freelists.org On Behalf Of David Sharples
    Sent: Thursday, February 16, 2006 11:36 AM
    To: fred_fred_1_at_hotmail.com
    Cc: oracle-l_at_freelists.org
    Subject: Re: Allowing users to execute shell scripts without seeing password

    sudo?

    you shouldnt need to give them read access to execute a script though - something wrong there maybe



    On 2/16/06, Fred Smith wrote:
    I've been trying to figure out a way that I can have my users allowed to
    login to the server (HP-UX) with their own account and run a shell script
    that's owned my me ... but I don't want them to be able to see the password.
    I had no luck just granting them execute on the shell script, they had to
    have read priviledges in order to execute it apparently.
    Any suggestions??


    Privileged/Confidential Information may be contained in this message or attachments hereto. Please advise immediately if you or your employer do not consent to Internet email for messages of this kind. Opinions, conclusions and other information in this message that do not relate to the official business of this company shall be understood as neither given nor endorsed by it.

    --
    http://www.freelists.org/webpage/oracle-l
  • Radoulov, Dimitre at Feb 17, 2006 at 6:36 pm
    Got error, trying to resend ...
    I've been trying to figure out a way that
    I can have my users allowed to login to the server (HP-UX)
    with their own account and run a shell script that's owned my me ...
    but I don't want them to be able to see the password.
    I had no luck just granting them execute on the shell script,
    they had to have read priviledges in order to execute it apparently.
    Any suggestions??
    As suggested on comp.unix shell you can use shell script compiler.

    You can try Francisco Javier Rosales García's shc:

    Home page:
    http://www.datsi.fi.upm.es/~frosal/

    Download link:
    http://www.datsi.fi.upm.es/~frosal/sources/shc-3.8.3.tgz

    Regards,
    Dimitre
  • Ken Naim at Feb 17, 2006 at 9:41 pm
    I am probably not be reading enough into the question, but here are my 2
    cents; just set permission to execute only with no read or write access.

    Ken Naim

    -----Original Message-----
    From: oracle-l-bounce_at_freelists.org
    On Behalf Of Radoulov, Dimitre
    Sent: Friday, February 17, 2006 12:36 PM
    To: oracle-l_at_freelists.org
    Subject: Re: Allowing users to execute shell scripts without seeing password

    Got error, trying to resend ...
    I've been trying to figure out a way that I can have my users allowed
    to login to the server (HP-UX) with their own account and run a shell
    script that's owned my me ...
    but I don't want them to be able to see the password.
    I had no luck just granting them execute on the shell script, they had
    to have read priviledges in order to execute it apparently.
    Any suggestions??
    As suggested on comp.unix shell you can use shell script compiler.

    You can try Francisco Javier Rosales García's shc:

    Home page:
    http://www.datsi.fi.upm.es/~frosal/

    Download link:
    http://www.datsi.fi.upm.es/~frosal/sources/shc-3.8.3.tgz

    Regards,
    Dimitre
  • David Sharples at Feb 17, 2006 at 9:45 pm
    thats been tried, you need read acess to execute it was proved to me a few
    posts back)

    On 2/17/06, Ken Naim wrote:

    >
    I am probably not be reading enough into the question, but here are my 2
    cents; just set permission to execute only with no read or write access.
    --
    http://www.freelists.org/webpage/oracle-l
  • Ken Naim at Feb 17, 2006 at 9:58 pm
    thanks,
    Ken

    From: David Sharples
    Sent: Friday, February 17, 2006 3:45 PM
    To: kennaim_at_gmail.com
    Cc: cichomitiko_at_gmail.com; oracle-l_at_freelists.org
    Subject: Re: Allowing users to execute shell scripts without seeing password

    thats been tried, you need read acess to execute it was proved to me a few
    posts back)

    On 2/17/06, Ken Naim wrote:

    I am probably not be reading enough into the question, but here are my 2
    cents; just set permission to execute only with no read or write access.
  • Joseph Amalraj at Feb 17, 2006 at 10:03 pm
    I think this is plaform dependent.


    On HP-UX i created a file under user "oracle" tmp.ksh
    cat tmp.ksh
    #!/usr/bin/ksh
    date

    then ran
    chmod 7711 tmp.ksh
    ls -l tmp.ksh
    -rws--s--x 1 oracle dba 20 Feb 17 16:51 tmp.ksh

    From another user I ran
    $ /opt/oracle/tmp.ksh
    Fri Feb 17 16:57:06 EST 2006

    Saving the file using "vi" resets the mode setuid bit.


    So it has to be set again



    This doesn't work in AIX


    Regards


    Joseph




    Ken Naim wrote:
    I am probably not be reading enough into the question, but here are my 2
    cents; just set permission to execute only with no read or write access.

    Ken Naim

    -----Original Message-----
    From: oracle-l-bounce_at_freelists.org
    On Behalf Of Radoulov, Dimitre
    Sent: Friday, February 17, 2006 12:36 PM
    To: oracle-l_at_freelists.org
    Subject: Re: Allowing users to execute shell scripts without seeing password

    Got error, trying to resend ...
    I've been trying to figure out a way that I can have my users allowed
    to login to the server (HP-UX) with their own account and run a shell
    script that's owned my me ...
    but I don't want them to be able to see the password.
    I had no luck just granting them execute on the shell script, they had
    to have read priviledges in order to execute it apparently.
    Any suggestions??
    As suggested on comp.unix shell you can use shell script compiler.

    You can try Francisco Javier Rosales García's shc:

    Home page:
    http://www.datsi.fi.upm.es/~frosal/

    Download link:
    http://www.datsi.fi.upm.es/~frosal/sources/shc-3.8.3.tgz

    Regards,
    Dimitre
  • Radoulov, Dimitre at Feb 17, 2006 at 10:16 pm

    I think this is plaform dependent.

    On HP-UX i created a file under user "oracle" tmp.ksh
    cat tmp.ksh
    #!/usr/bin/ksh
    date

    then ran
    chmod 7711 tmp.ksh
    ls -l tmp.ksh
    -rws--s--x 1 oracle dba 20 Feb 17 16:51 tmp.ksh

    From another user I ran
    $ /opt/oracle/tmp.ksh
    Fri Feb 17 16:57:06 EST 2006

    Saving the file using "vi" resets the mode setuid bit.

    So it has to be set again


    This doesn't work in AIX
    Thanks Joseph,
    I think the setuid+sticky bit is definitely the solution :)

    This is on Solaris 8:

    root_at_xxx # ls -l tmp.ksh
    --ws--s--t 1 root other 20 Feb 17 23:08 tmp.ksh
    root_at_xxx # su - oracle
    $ ls -l tmp.ksh
    --ws--s--t 1 root other 20 Feb 17 23:08 tmp.ksh
    $ ./tmp.ksh
    Fri Feb 17 23:14:03 MET 2006

    Regards,
    Dimitre
  • Bobak, Mark at Feb 17, 2006 at 10:36 pm
    Interesting....I can confirm that it works on Sparc-Solaris 9.


    I thought suid shell scripts were a thing of the past, due to security concerns. Seems they still work.....


    -Mark


    --
    Mark J. Bobak
    Senior Oracle Architect
    ProQuest Information & Learning

    "Exception: Some dividends may be reported as qualified dividends but are not qualified dividends. These include:

    * Dividends you received on any share of stock that you held for less than 61 days during the 121-day period that began 60 days before the ex-dividend date. The ex-dividend date is the first date following the declaration of a dividend on which the purchaser of a stock is not entitled to receive the next dividend payment. When counting the number of days you held the stock, include the day you disposed of the stock but not the day you acquired it. See the examples below. Also, when counting the number of days you held the stock, you cannot count certain days during which your risk of loss was diminished. See Pub. 550 for more details."

    --IRS, Form 1040-A Instruction Booklet, Line 9b: Qualified Dividends

    ________________________________

    From: oracle-l-bounce_at_freelists.org On Behalf Of Joseph Amalraj
    Sent: Friday, February 17, 2006 5:04 PM
    To: oracle-l_at_freelists.org
    Subject: RE: Allowing users to execute shell scripts without seeing password

    I think this is plaform dependent.

    On HP-UX i created a file under user "oracle" tmp.ksh
    cat tmp.ksh
    #!/usr/bin/ksh
    date

    then ran
    chmod 7711 tmp.ksh
    ls -l tmp.ksh
    -rws--s--x 1 oracle dba 20 Feb 17 16:51 tmp.ksh

    From another user I ran
    $ /opt/oracle/tmp.ksh
    Fri Feb 17 16:57:06 EST 2006

    Saving the file using "vi" resets the mode setuid bit.

    So it has to be set again

    This doesn't work in AIX

    Regards

    Joseph

    Ken Naim wrote:

    I am probably not be reading enough into the question, but here are my 2
    cents; just set permission to execute only with no read or write access.

    Ken Naim

    -----Original Message-----
    From: oracle-l-bounce_at_freelists.org
    On Behalf Of Radoulov, Dimitre
    Sent: Friday, February 17, 2006 12:36 PM
    To: oracle-l_at_freelists.org
    Subject: Re: Allowing users to execute shell scripts without seeing password

    Got error, trying to resend ...
    I've been trying to figure out a way that I can have my users allowed
    to login to the server (HP-UX) with their own account and run a shell
    script that's owned my me ...
    but I don't want them to be able to see the password.
    I had no luck just granting them execute on the shell script, they had
    to have read priviledges in order to execute it apparently.
    Any suggestions??
    As suggested on comp.unix shell you can use shell script compiler.

    You can try Francisco Javier Rosales García's shc:

    Home page:
    http://www.datsi.fi.upm.es/~frosal/

    Download link:
    http://www.datsi.fi.upm.es/~frosal/sources/shc-3.8.3.tgz

    Regards,
    Dimitre
  • Joseph Amalraj at Feb 18, 2006 at 12:24 am
    Security concerns ? Mark, please elaborate.


    Thanks

    "Bobak, Mark" wrote:

    Interesting....I can confirm that it works on Sparc-Solaris 9.


    I thought suid shell scripts were a thing of the past, due to security concerns. Seems they still work.....


    -Mark


    --
    Mark J. Bobak
    Senior Oracle Architect
    ProQuest Information & Learning
    "Exception: Some dividends may be reported as qualified dividends but are not qualified dividends. These include:
    ? Dividends you received on any share of stock that you held for less than 61 days during the 121-day period that began 60 days before the ex-dividend date. The ex-dividend date is the first date following the declaration of a dividend on which the purchaser of a stock is not entitled to receive the next dividend payment. When counting the number of days you held the stock, include the day you disposed of the stock but not the day you acquired it. See the examples below. Also, when counting the number of days you held the stock, you cannot count certain days during which your risk of loss was diminished. See Pub. 550 for more details.?
    --IRS, Form 1040-A Instruction Booklet, Line 9b: Qualified Dividends




    From: oracle-l-bounce_at_freelists.org On Behalf Of Joseph Amalraj
    Sent: Friday, February 17, 2006 5:04 PM
    To: oracle-l_at_freelists.org
    Subject: RE: Allowing users to execute shell scripts without seeing password



    I think this is plaform dependent.


    On HP-UX i created a file under user "oracle" tmp.ksh
    cat tmp.ksh
    #!/usr/bin/ksh
    date

    then ran
    chmod 7711 tmp.ksh
    ls -l tmp.ksh
    -rws--s--x 1 oracle dba 20 Feb 17 16:51 tmp.ksh

    From another user I ran
    $ /opt/oracle/tmp.ksh
    Fri Feb 17 16:57:06 EST 2006

    Saving the file using "vi" resets the mode setuid bit.


    So it has to be set again



    This doesn't work in AIX


    Regards


    Joseph




    Ken Naim wrote:
    I am probably not be reading enough into the question, but here are my 2
    cents; just set permission to execute only with no read or write access.

    Ken Naim

    -----Original Message-----
    From: oracle-l-bounce_at_freelists.org
    On Behalf Of Radoulov, Dimitre
    Sent: Friday, February 17, 2006 12:36 PM
    To: oracle-l_at_freelists.org
    Subject: Re: Allowing users to execute shell scripts without seeing password

    Got error, trying to resend ...
    I've been trying to figure out a way that I can have my users allowed
    to login to the server (HP-UX) with their own account and run a shell
    script that's owned my me ...
    but I don't want them to be able to see the password.
    I had no luck just granting them execute on the shell script, they had
    to have read priviledges in order to execute it apparently.
    Any suggestions??
    As suggested on comp.unix shell you can use shell script compiler.

    You can try Francisco Javier Rosales Garcí¡¦#39;s shc:

    Home page:
    http://www.datsi.fi.upm.es/~frosal/

    Download link:
    http://www.datsi.fi.upm.es/~frosal/sources/shc-3.8.3.tgz

    Regards,
    Dimitre
  • Radoulov, Dimitre at Feb 17, 2006 at 11:07 pm
    I think the setuid+sticky bit is definitely the solution :)
    Correcting myself: it's sticky bit + shebang:

    xxx:{root}:/app/oracle> cat tmp1.sh
    #!/usr/bin/ksh
    date
    xxx:{root}:/app/oracle> chmod 4501 tmp1.sh
    xxx:{root}:/app/oracle> ls -l tmp1.sh
    -r-s-----x 1 root other 20 Feb 17 23:51 tmp1.sh
    xxx:{root}:/app/oracle> su - oracle
    $ ls -l tmp1.sh
    -r-s-----x 1 root other 20 Feb 17 23:51 tmp1.sh
    $ ./tmp1.sh
    Fri Feb 17 23:59:11 MET 2006
    $ cat tmp1.sh
    cat: cannot open tmp1.sh

    Without shebang:

    xxx:{root}:/app/oracle> cat tmp1.sh
    #
    #!/usr/bin/ksh
    date
    xxx:{root}:/app/oracle> su - oracle
    $ ls -l tmp1.sh
    -r-s-----x 1 root other 22 Feb 18 00:01 tmp1.sh
    $ ./tmp1.sh
    ksh: ./tmp1.sh: cannot open
    $ truss tmp1.sh

    ..................................................
    brk(0x0003A2F0) = 0
    getuid() = 250 [250]
    getuid() = 250 [250]
    getgid() = 200 [200]
    getgid() = 200 [200]
    open64("./tmp1.sh", O_RDONLY) Err#13 EACCES
    ./tmp1.shwrite(2, " . / t m p 1 . s h", 9) = 9
    : write(2, " : ", 2) = 2
    ./tmp1.shwrite(2, " . / t m p 1 . s h", 9) = 9
    : write(2, " : ", 2) = 2
    cannot openwrite(2, " c a n n o t o p e n", 11) = 11

    write(2, "\n", 1) = 1
    llseek(0, 0, SEEK_CUR) = 40735

    _exit(1)

    Dimitre
  • Radoulov, Dimitre at Feb 17, 2006 at 11:19 pm
    Correcting myself: it's sticky bit + shebang:
    I meant set uid, not sticky bit, of course :)

    Dimitre
  • Michael Haddon at Feb 18, 2006 at 3:49 pm
    <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

    First, I would really need to know some more information, allowing
    users to log into their own Unix account, (any Unix), and then
    executing a shell script is not unknown, it is done all the time for
    different reasons and to perform different tasks. Whether it is to set
    up their environment or to drop them into a default application.
    Another good question would be 'what password?', what does this script
    do that it needs a password?, there are several ways to execute a script
    without displaying certain sensitive information. Just depends on what
    you want to do.
    I would not normally use the setuid bit where it is not absolutely
    needed. If it is used improperly it can create some serious security
    issues. There are plenty of alternatives like sudo, or maybe
    accomplishing the task without imbedding the password in the file.
    (best alternative).
    I would love to assist with this issue, if you can provide some more
    information I would be happy to help.
    Mike

    Ken Naim wrote:

    I am probably not be reading enough into the question, but here are my 2
    cents; just set permission to execute only with no read or write access.

    Ken Naim

    -----Original Message-----
    From: oracle-l-bounce@freelists.org
    On Behalf Of Radoulov, Dimitre
    Sent: Friday, February 17, 2006 12:36 PM
    To: oracle-l@freelists.org
    Subject: Re: Allowing users to execute shell scripts without seeing password

    Got error, trying to resend ...

    I've been trying to figure out a way that I can have my users allowed
    to login to the server (HP-UX) with their own account and run a shell
    script that's owned my me ...
    but I don't want them to be able to see the password.
    I had no luck just granting them execute on the shell script, they had
    to have read priviledges in order to execute it apparently.
    Any suggestions??

    As suggested on comp.unix shell you can use shell script compiler.

    You can try Francisco Javier Rosales García's shc:

    Home page:
    http://www.datsi.fi.upm.es/~frosal/

    Download link:
    http://www.datsi.fi.upm.es/~frosal/sources/shc-3.8.3.tgz

    Regards,
    Dimitre

    --
    http://www.freelists.org/webpage/oracle-l

    --
    http://www.freelists.org/webpage/oracle-l

    --
    http://www.freelists.org/webpage/oracle-l
  • Michael Haddon at Feb 18, 2006 at 3:50 pm
    <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

    Just for my .02 - The setuid bit sets the effective userid of the user
    calling the program to the user/group that owns the program. During the
    course of execution the program can accomplish any task, good or evil,
    that the owner can do.
    For example, the example posted below by Joseph. The example shows the
    program tmp.ksh is owned by 'oracle' and belongs to group 'dba'.
    If the calling user can cause the script/program to core dump or quit
    abnormally there used to be a very strong chance that the effective
    userid of the calling user would still be 'oracle'. This showed up
    years and years, (late 80's, early 90's), ago with the 'at' command in
    some pre SysVR4 systems. If you could core dump the at command while it
    was running, you were root.
    Now, today, most programs and shells have specific signal handling code
    for this, but, you have to treat the command as sensitive at minimum.
    Mike
    Joseph Amalraj wrote:

    Security concerns ? Mark, please elaborate.

    Thanks

    "Bobak, Mark"
    wrote:

    Interesting....I can confirm
    that it works on Sparc-Solaris 9.

    I thought suid shell scripts
    were a thing of the past, due to security concerns.  Seems they still
    work.....

    -Mark


    --
    Mark J. Bobak
    Senior Oracle Architect

    ProQuest Information & Learning
    "Exception:  Some dividends
    may be reported as qualified dividends but are not qualified
    dividends.  These include:
    ? Dividends you received on
    any share of stock that you held for less than 61 days during the
    121-day period that began 60 days before the ex-dividend date.&
    nbsp; The ex-dividend date is the first date following the declaration
    of a dividend on which the purchaser of a stock is not entitled to
    receive the next dividend payment. When counting the number of days you
    held the stock, include the day you disposed of the stock but not the
    day you acquired it. See the examples below. Also, when counting the
    number of days you held the stock, you cannot count certain days during
    which your risk of loss was diminished.  See Pub. 550 for more details.?
    --IRS, Form 1040-A
    Instruction Booklet, Line 9b:  Qualified Dividends


    From:
    oracle-l-bounce@freelists.org

    On
    Behalf Of Joseph Amalraj
    Sent: Friday, February 17, 2006 5:04 PM
    To: oracle-l@freelists.org
    Subject: RE: Allowing users to execute shell scripts
    without seeing password

    I think this is plaform dependent.

    On HP-UX  i created a file under user "oracle" tmp.ksh
    cat tmp.ksh
    #!/usr/bin/ksh
    date

    then ran
    chmod 7711 tmp.ksh
    ls -l tmp.ksh
    -rws--s--x   1 oracle     dba             20 Feb 17 16:51 tmp.ksh

    From another user I ran
    $ /opt/oracle/tmp.ksh
    Fri Feb 17 16:57:06 EST 2006

    Saving the file using "vi" resets the mode setuid bit.

    So it has to be set again


    This doesn't work in AIX

    Regards

    Joseph



    < I>Ken Naim
    wrote:
    I
    am probably not be reading enough into the question, but here are my 2
    cents; just set permission to execute only with no read or write access.

    Ken Naim

    -----Original Message-----
    From: oracle-l-bounce@freelists.org

    On Behalf Of Radoulov, Dimitre
    Sent: Friday, February 17, 2006 12:36 PM
    To: oracle-l@freelists.org
    Subject: Re: Allowing users to execute shell scripts without seeing
    password

    Got error, trying to resend ...
    I've been trying to figure out a way that I can have my users allowed
    to login to the server (HP-UX) with their own account and run a shell
    script that's owned my me ...
    but I don't want them to be able to see the password.
    I had no luck just granting them execute on the shell script, t hey had
    to have read priviledges in order to execute it apparently.
    Any suggestions??
    As suggested on comp.unix shell you can use shell script compiler.

    You can try Francisco Javier Rosales Garcí¡¦#39;s shc:

    Home page:
    http://www.datsi.fi.upm.es/~frosal/

    Download link:
    http://www.datsi.fi.upm.es/~frosal/sources/shc-3.8.3.tgz

    Regards,
    Dimitre
  • Joseph Amalraj at Feb 19, 2006 at 4:38 am
    After doing some reading, I agree, that setting suid for shell scripts is poses security risks. Probably the solution is not to use Shell, but some else like Perl.
      Â

      Thanks
      Â

      Joseph

    Michael Haddon wrote:
      Just for my .02 - The setuid bit sets the effective userid of the user calling the program to the user/group that owns the program. During the course of execution the program can accomplish any task, good or evil, that the owner can do.

    For example, the example posted below by Joseph. The example shows the program tmp.ksh is owned by 'oracle' and belongs to group 'dba'.

    If the calling user can cause the script/program to core dump or quit abnormally there used to be a very strong chance that the effective userid of the calling user would still be 'oracle'. This showed up years and years, (late 80's, early 90's), ago with the 'at' command in some pre SysVR4 systems. If you could core dump the at command while it was running, you were root.

    Now, today, most programs and shells have specific signal handling code for this, but, you have to treat the command as sensitive at minimum.

    Mike

    Joseph Amalraj wrote: Security concerns ? Mark, please elaborate.
      Â

      Thanks

    "Bobak, Mark" wrote:

        Interesting....I can confirm that it works on Sparc-Solaris 9.
      Â

      I thought suid shell scripts were a thing of the past, due to security concerns. Seems they still work.....
      Â

      -Mark
      Â

      --
    Mark J. Bobak
    Senior Oracle Architect
    ProQuest Information & Learning
      "Exception: Some dividends may be reported as qualified dividends but are not qualified dividends. These include:
      ? Dividends you received on any share of stock that you held for less than 61 days during the 121-day period that began 60 days before the ex-dividend date.& nbsp; The ex-dividend date is the first date following the declaration of a dividend on which the purchaser of a stock is not entitled to receive the next dividend payment. When counting the number of days you held the stock, include the day you disposed of the stock but not the day you acquired it. See the examples below. Also, when counting the number of days you held the stock, you cannot count certain days during which your risk of loss was diminished. See Pub. 550 for more details.?
        --IRS, Form 1040-A Instruction Booklet, Line 9b: Qualified Dividends
      Â

       Â

      From: oracle-l-bounce_at_freelists.org On Behalf Of Joseph Amalraj
    Sent: Friday, February 17, 2006 5:04 PM
    To: oracle-l_at_freelists.org
    Subject: RE: Allowing users to execute shell scripts without seeing password

      I think this is plaform dependent.
      Â

      On HP-UX i created a file under user "oracle" tmp.ksh
    cat tmp.ksh
    #!/usr/bin/ksh
    date

      then ran
      chmod 7711 tmp.ksh
    ls -l tmp.ksh
    -rws--s--x 1 oracle dba 20 Feb 17 16:51 tmp.ksh

      From another user I ran
       $ /opt/oracle/tmp.ksh
    Fri Feb 17 16:57:06 EST 2006

      Saving the file using "vi" resets the mode setuid bit.
      Â

      So it has to be set again
      Â
      Â

      This doesn't work in AIX
      Â

      Regards
      Â

      Joseph
      Â
      Â
     Â

    < I>Ken Naim wrote:
      I am probably not be reading enough into the question, but here are my 2
    cents; just set permission to execute only with no read or write access.

    Ken Naim

    -----Original Message-----
    From: oracle-l-bounce_at_freelists.org
    On Behalf Of Radoulov, Dimitre
    Sent: Friday, February 17, 2006 12:36 PM
    To: oracle-l_at_freelists.org
    Subject: Re: Allowing users to execute shell scripts without seeing password

    Got error, trying to resend ...
    I've been trying to figure out a way that I can have my users allowed
    to login to the server (HP-UX) with their own account and run a shell
    script that's owned my me ...
    but I don't want them to be able to see the password.
    I had no luck just granting them execute on the shell script, t hey had
    to have read priviledges in order to execute it apparently.
    Any suggestions??
    As suggested on comp.unix shell you can use shell script compiler.

    You can try Francisco Javier Rosales Garcí¡¦#39;s shc:

    Home page:
    http://www.datsi.fi.upm.es/~frosal/

    Download link:
    http://www.datsi.fi.upm.es/~frosal/sources/shc-3.8.3.tgz

    Regards,
    Dimitre
  • Mladen Gogala at Feb 19, 2006 at 5:56 am

    On 02/18/2006 11:38:01 PM, Joseph Amalraj wrote:
    After doing some reading, I agree, that setting suid for shell scripts is poses
    security risks. Probably the solution is not to use Shell, but some else like Perl.
    So, if switching UID is dangerous with a shell script, it will somehow be
    rendered harmless if you use Perl, which allows all kinds of programming
    tricks and hacks?
  • Michael Haddon at Feb 19, 2006 at 1:00 pm
    <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

    There is nothing Magic about perl that would solve the security
    issues that come up when using a 'setuid' bit on the executible. The
    setuid capability is a Unix capability and not one specific to the
    shell. A setuid script has it's risks if it is written in perl, ksh,
    bash, awk, tck/tkl, or whatever. It just needs to handle any security
    issues, if they exist, in the code.
    Most scripts really don't need the setuid bit, those that do, can use
    the 'trap' in the shell to handle any post signal processing. One
    example of this can be found in the /etc/profile script that is
    executed by everyone that logs into a Unix system. Part of the login
    process executes this script to set up a system wide default
    environment.
    The beginning of the script uses the trap command to set up signals
    that need to be handled and the end of the script releases the trap.
    My point is that sometimes the setuid bit can help accomplish a task
    that would otherwise take some considerable time to design and code.
    You just have to be aware of it's use and test it thoroughly.
    Hope this helps
    Mike
    Mladen Gogala wrote:

    On 02/18/2006 11:38:01 PM, Joseph Amalraj wrote:

    After doing some reading, I agree, that setting suid for shell scripts is poses
    security risks. Probably the solution is not to use Shell, but some else like Perl.

    So, if switching UID is dangerous with a shell script, it will somehow be
    rendered harmless if you use Perl, which allows all kinds of programming
    tricks and hacks?
  • Joseph Amalraj at Feb 19, 2006 at 2:10 pm
    Thanks was making me aware of the capabilities of Perl.


    Had tried to use, trap command, but users in the system always got around it in the long run. The solution, that I had to implement was to use the shell script name in /etc/passwd file instead of the name of the shell.


    Interpretive languages need to read the script and thereby need a read privilege on the file. Compiled languages could also have the same deficiencies, if some-one tried to debug a core dump file.


    Main problem is with password being stored in files. How can scripts/programs run by some other user (other than owner) utilize this password, without actually being able to see it. Basically, this boils down to sharing a password.


    One solution for this could be that every user, who runs the script/program should have his own password. I have liked Oracle os authenication not "remote os authent'. but this can be only used if the database is local.


    Regards


    Joseph


    Michael Haddon wrote:
    There is nothing Magic about perl that would solve the security issues that come up when using a 'setuid' bit on the executible. The setuid capability is a Unix capability and not one specific to the shell. A setuid script has it's risks if it is written in perl, ksh, bash, awk, tck/tkl, or whatever. It just needs to handle any security issues, if they exist, in the code.

    Most scripts really don't need the setuid bit, those that do, can use the 'trap' in the shell to handle any post signal processing. One example of this can be found in the /etc/profile script that is executed by everyone that logs into a Unix system. Part of the login process executes this script to set up a system wide default environment.

    The beginning of the script uses the trap command to set up signals that need to be handled and the end of the script releases the trap.

    My point is that sometimes the setuid bit can help accomplish a task that would otherwise take some considerable time to design and code. You just have to be aware of it's use and test it thoroughly.

    Hope this helps
    Mike

    Mladen Gogala wrote:
    On 02/18/2006 11:38:01 PM, Joseph Amalraj wrote:


    After doing some reading, I agree, that setting suid for shell scripts is poses security risks. Probably the solution is not to use Shell, but some else like Perl.

    So, if switching UID is dangerous with a shell script, it will somehow be rendered harmless if you use Perl, which allows all kinds of programming tricks and hacks?
    -- http://www.freelists.org/webpage/oracle-l
  • Michael Haddon at Feb 19, 2006 at 2:25 pm
    <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

    One solution you might consider is to store the password in another
    file that is read in by the setuid script. As the user executes the
    script, which he/she has read permissions on, the script can read an
    encrypted/plain text file that is only readable by the owner.
    Mike
    Joseph Amalraj wrote:

    Thanks was making me aware of the capabilities of Perl.

    Had tried to use, trap command,  but users in the system always
    got around it in the long run. The solution, that I had to implement
    was to use the shell script name in /etc/passwd file instead of the
    name of the shell.

    Interpretive languages need to read the script and thereby need
    a read privilege on the file. Compiled languages could also have the
    same deficiencies, if some-one tried to debug a core dump file.

    Main problem is with password being stored in files. How can
    scripts/programs run by some other user (other than owner) utilize this
    password, without actually being able to see it. Basically, this boils
    down to sharing a password.

    One solution for this could be that every user, who runs the
    script/program should have his own password. I have liked Oracle os
    authenication not "remote os authent'. but this can be only used if the
    database is local.

    Regards

    Joseph

    Michael Haddon wrote:
    There
    is nothing Magic about perl that would solve the security
    issues that come up when using a 'setuid' bit on the executible. The
    setuid capability is a Unix capability and not one specific to the
    shell. A setuid script has it's risks if it is written in perl, ksh,
    bash, awk, tck/tkl, or whatever. It just needs to handle any security
    issues, if they exist, in the code.

    Most scripts really don't need the setuid bit, those that do, can use
    the 'trap' in the shell to handle any post signal processing. One
    example of this can be found in the /etc/profile script that is
    executed by everyone that logs into a Unix system. Part of the login
    process executes this script to set up a system wide default
    environment.

    The beginning of the script uses the trap command to set up signals
    that need to be handled and the end of the script releases the trap.

    My point is that sometimes the setuid bit can help accomplish a task
    that would otherwise take some considerable time to design and code.
    You just have to be aware of it's use and test it thoroughly.

    Hope this helps
    Mike

    Mladen Gogala wrote:

    On 02/18/2006 11:38:01 PM, Joseph Amalraj wrote:

    After doing some reading, I agree, that setting suid for shell scripts is poses security risks. Probably the solution is not to use Shell, but some else like Perl.

    So, if switching UID is dangerous with a shell script, it will somehow be rendered harmless if you use Perl, which
    allows all kinds of programming tricks and hacks?

    -- http://www.freelists.org/webpage/oracle-l
  • Radoulov, Dimitre at Feb 19, 2006 at 2:35 pm

    One solution you might consider is to store the password in another file
    that is read in by the setuid script.
    As the user executes the script, which he/she has read permissions on,
    the script can read an encrypted/plain text file that is only readable by
    the owner.
    May be I'm missing something but how this case differs from the previous
    solution: script with setuid without read access?

    Regards,
    Dimitre
  • Michael Haddon at Feb 19, 2006 at 4:27 pm
    <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

    It's not really. My point was that there are alot of ways to do this.
    From what I understand, the problem is to allow Unix accounts to log
    into a Unix server that may or may not be running an Oracle server.
    Once this log in is successfull the user is to be taken straight into
    SQL*Plus using the main schema name/password and there are concerns
    about the login script needing a privileged password to get access and
    having to be readable by whomever is executing it.
    There are really a hundred ways to do this. The suggestion below
    doesn't solve anything. If I had to accomplish this I wouldn't do it by
    replacing the shell command in the password file, or by using a setuid
    script. What I would do is call the script from the /etc/profile. Maybe
    put  some code in the script, (/etc/profile), to control which Unix
    accounts call it.
    Either way - there are more concerns than just the setuid. You have to
    make sure the user cannot bang out of SQL if you don't want
    them to access the Unix OS.
    The main point is that there is probably a better way - This just
    depends on what you want to accomplish. If the users are continually
    snooping for ways to get around the controls then you have your work
    cut out for you. Sometimes I find it much easier to record actions and
    publish policy about acceptable uses of the system and make sure you
    follow up when users attempt to do something they're not supposed to.
    Almost every time I see something that is not supposed to be done I can
    prevent it by just informaing the specific user that you know and let
    him understand the problems he/she can bring upon themselves.
    You can either lock them down with large fences, or put up some small
    fences and make sure they see the big dog on the other side of it.
    Mike
    Radoulov, Dimitre wrote:

    One solution you might consider is to store
    the password in another file that is read in by the setuid script.

    As the user executes the script, which he/she has read permissions on,

    the script can read an encrypted/plain text file that is only readable
    by the owner.

    May be I'm missing something but how this case differs from the
    previous solution: script with setuid without read access?

    Regards,

    Dimitre
  • Joseph Amalraj at Feb 19, 2006 at 5:13 pm
    Hi,


    Please let me know what is the issue with putting the script name in the /etc/passwd, other than it being cumbersome.
    In this case the script does not need setuid bit.


    Even while executing /etc/profile, what would happen if the user pressed "^C" or quit, before executing the relevent portion of the /etc/profile. In this case, the user has access to unix shell prompt.


    Joseph


    Michael Haddon wrote:
    It's not really. My point was that there are alot of ways to do this.

    From what I understand, the problem is to allow Unix accounts to log into a Unix server that may or may not be running an Oracle server. Once this log in is successfull the user is to be taken straight into SQL*Plus using the main schema name/password and there are concerns about the login script needing a privileged password to get access and having to be readable by whomever is executing it.

    There are really a hundred ways to do this. The suggestion below doesn't solve anything. If I had to accomplish this I wouldn't do it by replacing the shell command in the password file, or by using a setuid script. What I would do is call the script from the /etc/profile. Maybe put some code in the script, (/etc/profile), to control which Unix accounts call it.

    Either way - there are more concerns than just the setuid. You have to make sure the user cannot bang out of SQL if you don't want them to access the Unix OS.

    The main point is that there is probably a better way - This just depends on what you want to accomplish. If the users are continually snooping for ways to get around the controls then you have your work cut out for you. Sometimes I find it much easier to record actions and publish policy about acceptable uses of the system and make sure you follow up when users attempt to do something they're not supposed to. Almost every time I see something that is not supposed to be done I can prevent it by just informaing the specific user that you know and let him understand the problems he/she can bring upon themselves.

    You can either lock them down with large fences, or put up some small fences and make sure they see the big dog on the other side of it.

    Mike

    Radoulov, Dimitre wrote: One solution you might consider is to store the password in another file that is read in by the setuid script.
    As the user executes the script, which he/she has read permissions on,
    the script can read an encrypted/plain text file that is only readable by the owner.

    May be I'm missing something but how this case differs from the previous solution: script with setuid without read access?

    Regards,
    Dimitre
  • Michael Haddon at Feb 19, 2006 at 6:52 pm
    <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

    There isn't anything wrong with putting it into the password file, it
    is just another way to do it. However, the capability to do this in the
    password file wasn't designed to be used for that purpose
    The /etc/profile has the trap command to prevent ^C from effectively
    halting the the script while it is being executed.
    Mike
    Joseph Amalraj wrote:

    Hi,

    Please let me know what is the issue with putting the script
    name in the /etc/passwd, other than it being cumbersome.
    In this case the script does not need setuid bit.

    Even while executing /etc/profile, what would happen if the user
    pressed "^C" or quit, before executing the relevent portion of the
    /etc/profile. In this case, the user has access to unix shell prompt.

    Joseph

    Michael Haddon wrote:
    It's
    not really. My point was that there are alot of ways to do this.

    From what I understand, the problem is to allow Unix accounts to log
    into a Unix server that may or may not be running an Oracle server.
    Once this log in is successfull the user is to be taken straight into
    SQL*Plus using the ma in schema name/password and there are concerns
    about the login script needing a privileged password to get access and
    having to be readable by whomever is executing it.

    There are really a hundred ways to do this. The suggestion below
    doesn't solve anything. If I had to accomplish this I wouldn't do it by
    replacing the shell command in the password file, or by using a setuid
    script. What I would do is call the script from the /etc/profile. Maybe
    put  some code in the script, (/etc/profile), to control which Unix
    accounts call it.

    Either way - there are more concerns than just the setuid. You have to
    make sure the user cannot bang out of SQL if you don't want
    them to access the Unix OS.

    The main point is that there is probably a better way - This just
    depends on what you want to accomplish. If the users are continually
    snooping for ways to get around the controls then you have your work
    cut out for you. Sometimes I find it much easier to record a ctions and
    publish policy about acceptable uses of the system and make sure you
    follow up when users attempt to do something they're not supposed to.
    Almost every time I see something that is not supposed to be done I can
    prevent it by just informaing the specific user that you know and let
    him understand the problems he/she can bring upon themselves.

    You can either lock them down with large fences, or put up some small
    fences and make sure they see the big dog on the other side of it.

    Mike

    Radoulov, Dimitre wrote:

    One solution you might consider is to
    store the password in another file that is read in by the setuid
    script.
    As the user executes the script, which he/she has read permissions on,
    the script can read an encrypted/plain text file that is only readable
    by the owner.

    May be I'm missing something but how this case diffe rs from the
    previous solution: script with setuid without read access?

    Regards,
    Dimitre
  • Joseph Amalraj at Feb 20, 2006 at 2:22 pm
    Hi Michael,


    What if the user enters a break or quit before the trap command.


    In one of the previous jobs, there were more than a 1000 users, I had set trap command at the begining of the .profile.


    Still they used to manage to get to the "$" prompt.


    Regards


    Joseph

    Michael Haddon wrote:


    There isn't anything wrong with putting it into the password file, it is just another way to do it. However, the capability to do this in the password file wasn't designed to be used for that purpose

    The /etc/profile has the trap command to prevent ^C from effectively halting the the script while it is being executed.

    Mike

    Joseph Amalraj wrote: Hi,


    Please let me know what is the issue with putting the script name in the /etc/passwd, other than it being cumbersome.
    In this case the script does not need setuid bit.


    Even while executing /etc/profile, what would happen if the user pressed "^C" or quit, before executing the relevent portion of the /etc/profile. In this case, the user has access to unix shell prompt.


    Joseph


    Michael Haddon wrote:
    It's not really. My point was that there are alot of ways to do this.

    From what I understand, the problem is to allow Unix accounts to log into a Unix server that may or may not be running an Oracle server. Once this log in is successfull the user is to be taken straight into SQL*Plus using the ma in schema name/password and there are concerns about the login script needing a privileged password to get access and having to be readable by whomever is executing it.

    There are really a hundred ways to do this. The suggestion below doesn't solve anything. If I had to accomplish this I wouldn't do it by replacing the shell command in the password file, or by using a setuid script. What I would do is call the script from the /etc/profile. Maybe put some code in the script, (/etc/profile), to control which Unix accounts call it.

    Either way - there are more concerns than just the setuid. You have to make sure the user cannot bang out of SQL if you don't want them to access the Unix OS.

    The main point is that there is probably a better way - This just depends on what you want to accomplish. If the users are continually snooping for ways to get around the controls then you have your work cut out for you. Sometimes I find it much easier to record a ctions and publish policy about acceptable uses of the system and make sure you follow up when users attempt to do something they're not supposed to. Almost every time I see something that is not supposed to be done I can prevent it by just informaing the specific user that you know and let him understand the problems he/she can bring upon themselves.

    You can either lock them down with large fences, or put up some small fences and make sure they see the big dog on the other side of it.

    Mike

    Radoulov, Dimitre wrote: One solution you might consider is to store the password in another file that is read in by the setuid script.
    As the user executes the script, which he/she has read permissions on,
    the script can read an encrypted/plain text file that is only readable by the owner.

    May be I'm missing something but how this case diffe rs from the previous solution: script with setuid without read access?

    Regards,
    Dimitre
  • Jared Still at Feb 19, 2006 at 5:47 pm

    On 2/19/06, Michael Haddon wrote:
    One solution you might consider is to store the password in another file
    that is read in by the setuid script. As the user executes the script, which
    he/she has read permissions on, the script can read an encrypted/plain text
    file that is only readable by the owner.
    If the user has read permissions on the password file, as would
    be required by this scenario, then nothing is solved.

    It does make it much easier for the user to access the passwords
    directly, as they are now stored in one place.

    A better solution is a password server that stores the passwords
    in an encrypted file, authenticates users and allows them to
    retrieve only the passwords they are authorized to see.

    We are implementing Enterprise Password Server from Argosy
    Telecrest to do that for the SA's for server passwords.

    I use a password server written in Perl that allows retrieving passwords
    from the command line (or in scripts) and has an API for Perl.

    Well of course it is written in Perl.

    See http://jaredstill.com/books.html

    If you get the password server running, ask me and I will supply the
    one that works with an encrypted password file.

    It has its shortcomings. It should work with certificates rather than a
    passphrase stored in a users file. Lack of time and insufficient motivation
    have prevented that particular problem from being resolved.

    It is however much better than a user-readable password file.

    Jared Still
    Certifiable Oracle DBA and Part Time Perl Evangelist
  • Joseph Amalraj at Feb 20, 2006 at 3:39 pm
    Basically, the /etc/password file is also a password server.
    If the desired script is put in place of the shell, the 7th item of the line. This userid can be become to an application id.


    Users who have to use this script will have to su to it and enter the application password. It is also possible to limit the number of users who can su to the application id (this depends on the unix platform).


    Joseph Amalraj

    Jared Still wrote:


    If the user has read permissions on the password file, as would
    be required by this scenario, then nothing is solved.

    It does make it much easier for the user to access the passwords
    directly, as they are now stored in one place.

    A better solution is a password server that stores the passwords
    in an encrypted file, authenticates users and allows them to
    retrieve only the passwords they are authorized to see.

    We are implementing Enterprise Password Server from Argosy
    Telecrest to do that for the SA's for server passwords.

    I use a password server written in Perl that allows retrieving passwords
    from the command line (or in scripts) and has an API for Perl.

    Well of course it is written in Perl.

    See http://jaredstill.com/books.html

    If you get the password server running, ask me and I will supply the
    one that works with an encrypted password file.

    It has its shortcomings. It should work with certificates rather than a
    passphrase stored in a users file. Lack of time and insufficient motivation
    have prevented that particular problem from being resolved.

    It is however much better than a user-readable password file.

    Jared Still
    Certifiable Oracle DBA and Part Time Perl Evangelist

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouporacle-l @
categoriesoracle
postedFeb 16, '06 at 6:29p
activeFeb 20, '06 at 3:39p
posts34
users13
websiteoracle.com

People

Translate

site design / logo © 2022 Grokbase