SUBMIT command - VMS

This is a discussion on SUBMIT command - VMS ; Hello, About Submit command, if I use /user=scott, dose VMS check user's password? Thanks...

+ Reply to Thread
Page 1 of 5 1 2 3 ... LastLast
Results 1 to 20 of 87

Thread: SUBMIT command

  1. SUBMIT command

    Hello,

    About Submit command, if I use /user=scott, dose VMS check user's
    password?

    Thanks


  2. Re: SUBMIT command

    In article <1193149624.407810.325610@t8g2000prg.googlegroups.c om>, a13365@yahoo.com writes:
    >About Submit command, if I use /user=scott, dose VMS check user's
    >password?


    No, but you need elevated privileges in order to use this qualifier.

    Regards,
    Christoph Gartmann

    --
    Max-Planck-Institut fuer Phone : +49-761-5108-464 Fax: -452
    Immunbiologie
    Postfach 1169 Internet: gartmann@immunbio dot mpg dot de
    D-79011 Freiburg, Germany
    http://www.immunbio.mpg.de/home/menue.html

  3. Re: SUBMIT command

    On Oct 23, 10:47 am, gartm...@nonsense.immunbio.mpg.de (Christoph
    Gartmann) wrote:
    > In article <1193149624.407810.325...@t8g2000prg.googlegroups.c om>, a13...@yahoo.com writes:
    > >About Submit command, if I use /user=scott, dose VMS check user's
    > >password?

    >
    > No, but you need elevated privileges in order to use this qualifier.
    >
    > Regards,
    > Christoph Gartmann
    >
    > --
    > Max-Planck-Institut fuer Phone : +49-761-5108-464 Fax: -452
    > Immunbiologie
    > Postfach 1169 Internet: gartmann@immunbio dot mpg dot de
    > D-79011 Freiburg, Germany
    > http://www.immunbio.mpg.de/home/menue.html


    Hello Christoph?

    What kind privileges I need to check?

    Thanks.


  4. Re: SUBMIT command

    In article <1193153254.512670.15500@t8g2000prg.googlegroups.co m>, a13365@yahoo.com writes:
    > What kind privileges I need to check?


    $ HELP SUBMIT /USER
    SUBMIT

    /USER

    /USER=username

    Requires CMKRNL (change mode to kernel) privilege and read (R)
    and write (W) access to the user authorization file (UAF).

  5. Re: SUBMIT command

    a13365@yahoo.com wrote:
    > Hello,
    >
    > About Submit command, if I use /user=scott, dose VMS check user's
    > password?
    >
    > Thanks
    >


    SUBMIT /USER requires privilege. If you have the necessary privilege
    you don't need the password. If you don't have the privilege the
    command will fail.


  6. Re: SUBMIT command

    In article <4$VTv9Rz+Npg@eisner.encompasserve.org>,
    briggs@encompasserve.org writes:
    > In article <1193153254.512670.15500@t8g2000prg.googlegroups.co m>, a13365@yahoo.com writes:
    >> What kind privileges I need to check?

    >
    > $ HELP SUBMIT /USER
    > SUBMIT
    >
    > /USER
    >
    > /USER=username
    >
    > Requires CMKRNL (change mode to kernel) privilege and read (R)
    > and write (W) access to the user authorization file (UAF).


    Ohmigod!!!! There is actually something that Unix can do that
    VMS can't do (at least not without elevated priviledges on the
    VMS side!!)

    bill

    --
    Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
    bill@cs.scranton.edu | and a sheep voting on what's for dinner.
    University of Scranton |
    Scranton, Pennsylvania | #include

  7. Re: SUBMIT command

    Bill Gunshannon wrote:
    > In article <4$VTv9Rz+Npg@eisner.encompasserve.org>,
    > briggs@encompasserve.org writes:
    >
    >>In article <1193153254.512670.15500@t8g2000prg.googlegroups.co m>, a13365@yahoo.com writes:
    >>
    >>>What kind privileges I need to check?

    >>
    >>$ HELP SUBMIT /USER
    >>SUBMIT
    >>
    >> /USER
    >>
    >> /USER=username
    >>
    >> Requires CMKRNL (change mode to kernel) privilege and read (R)
    >> and write (W) access to the user authorization file (UAF).

    >
    >
    > Ohmigod!!!! There is actually something that Unix can do that
    > VMS can't do (at least not without elevated priviledges on the
    > VMS side!!)
    >
    > bill
    >


    And just how does Unix run something as another user without being root
    (privelege equivalent)??


  8. unix "batch processing"

    On Tue, 23 Oct 2007, Bill Gunshannon wrote:

    > In article <4$VTv9Rz+Npg@eisner.encompasserve.org>,
    > briggs@encompasserve.org writes:
    >> In article <1193153254.512670.15500@t8g2000prg.googlegroups.co m>,
    >> a13365@yahoo.com writes:
    >>> What kind privileges I need to check?

    >>
    >> $ HELP SUBMIT /USER
    >> SUBMIT
    >>
    >> /USER
    >>
    >> /USER=username
    >>
    >> Requires CMKRNL (change mode to kernel) privilege and read (R)
    >> and write (W) access to the user authorization file (UAF).

    >
    > Ohmigod!!!! There is actually something that Unix can do that
    > VMS can't do (at least not without elevated priviledges on the
    > VMS side!!)


    I have never known how to do something in Linux that I would do in
    batch in VMS. Perhaps the UNIX facility you refer to exists in Linux?

    What UNIX facility do you refer to? How is it similar to and
    different from from batch jobs in VMS. How would I have to change my
    thinking to recognize it? How and when is the specified user
    protected against unauthorized jobs run on his behalf?

    Thanks for educating me.


    --

    Rob Brown b r o w n a t g m c l d o t c o m
    G. Michaels Consulting Ltd. (780)438-9343 (voice)
    Edmonton (780)437-3367 (FAX)
    http://gmcl.com/


  9. Re: SUBMIT command

    In article <471E2341.30707@comcast.net>,
    "Richard B. Gilbert" writes:
    > Bill Gunshannon wrote:
    >> In article <4$VTv9Rz+Npg@eisner.encompasserve.org>,
    >> briggs@encompasserve.org writes:
    >>
    >>>In article <1193153254.512670.15500@t8g2000prg.googlegroups.co m>, a13365@yahoo.com writes:
    >>>
    >>>>What kind privileges I need to check?
    >>>
    >>>$ HELP SUBMIT /USER
    >>>SUBMIT
    >>>
    >>> /USER
    >>>
    >>> /USER=username
    >>>
    >>> Requires CMKRNL (change mode to kernel) privilege and read (R)
    >>> and write (W) access to the user authorization file (UAF).

    >>
    >>
    >> Ohmigod!!!! There is actually something that Unix can do that
    >> VMS can't do (at least not without elevated priviledges on the
    >> VMS side!!)
    >>
    >> bill
    >>

    >
    > And just how does Unix run something as another user without being root
    > (privelege equivalent)??
    >


    Prompts for the password.

    bill

    --
    Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
    bill@cs.scranton.edu | and a sheep voting on what's for dinner.
    University of Scranton |
    Scranton, Pennsylvania | #include

  10. Re: unix "batch processing"

    In article ,
    Rob Brown writes:
    > On Tue, 23 Oct 2007, Bill Gunshannon wrote:
    >
    >> In article <4$VTv9Rz+Npg@eisner.encompasserve.org>,
    >> briggs@encompasserve.org writes:
    >>> In article <1193153254.512670.15500@t8g2000prg.googlegroups.co m>,
    >>> a13365@yahoo.com writes:
    >>>> What kind privileges I need to check?
    >>>
    >>> $ HELP SUBMIT /USER
    >>> SUBMIT
    >>>
    >>> /USER
    >>>
    >>> /USER=username
    >>>
    >>> Requires CMKRNL (change mode to kernel) privilege and read (R)
    >>> and write (W) access to the user authorization file (UAF).

    >>
    >> Ohmigod!!!! There is actually something that Unix can do that
    >> VMS can't do (at least not without elevated priviledges on the
    >> VMS side!!)

    >
    > I have never known how to do something in Linux that I would do in
    > batch in VMS. Perhaps the UNIX facility you refer to exists in Linux?


    Of course it does.

    >
    > What UNIX facility do you refer to?


    Actually, I was just refering to the ability to do it as another
    user without elevated priviledges.

    > How is it similar to and
    > different from from batch jobs in VMS.


    I guess I would need to know what you think of as "batch jobs". To
    me that just means running non-interactive processes. That can be
    done in Unix either with the "at" command for later execution or
    with the "&" symbol to run the process in the background.

    > How would I have to change my
    > thinking to recognize it? How and when is the specified user
    > protected against unauthorized jobs run on his behalf?


    The same way he is protected from someone loggin in and running stuff
    as him. Password is required. Now, granted, it is not a good thing
    to give out yur password and is forbidden in many venue (like DOD) but
    I can think of and come up with places where this could still be used
    safely and would meet a need.

    >
    > Thanks for educating me.


    Hope what I said above helps at least a littel, if you have any more
    questions, feel free to email me directly as I am sure the majority
    here have no desire to have their mistaken understanding of Unix
    corrected.

    bill


    --
    Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
    bill@cs.scranton.edu | and a sheep voting on what's for dinner.
    University of Scranton |
    Scranton, Pennsylvania | #include

  11. Re: SUBMIT command

    In article <5o6l41Fktd8gU1@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:
    > In article <4$VTv9Rz+Npg@eisner.encompasserve.org>,
    > briggs@encompasserve.org writes:
    >> In article <1193153254.512670.15500@t8g2000prg.googlegroups.co m>, a13365@yahoo.com writes:
    >>> What kind privileges I need to check?

    >>
    >> $ HELP SUBMIT /USER
    >> SUBMIT
    >>
    >> /USER
    >>
    >> /USER=username
    >>
    >> Requires CMKRNL (change mode to kernel) privilege and read (R)
    >> and write (W) access to the user authorization file (UAF).

    >
    > Ohmigod!!!! There is actually something that Unix can do that
    > VMS can't do (at least not without elevated priviledges on the
    > VMS side!!)


    There are lots of things VMS considers to be security relevant
    where Unix does not care.

  12. Re: unix "batch processing"

    In article <5o6nn2Flf59dU2@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:

    > The same way he is protected from someone loggin in and running stuff
    > as him. Password is required. Now, granted, it is not a good thing
    > to give out yur password and is forbidden in many venue (like DOD) but
    > I can think of and come up with places where this could still be used
    > safely and would meet a need.


    I can think of no situation on VMS where sharing of passwords would be
    reasonable (single user systems do not count, since there iws no sharing).

    If you want to fully share access, then create usernames with a shared
    UIC. They have the same rights to data but separate audit identities.

  13. Re: unix "batch processing"

    In article ,
    Kilgallen@SpamCop.net (Larry Kilgallen) writes:
    > In article <5o6nn2Flf59dU2@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:
    >
    >> The same way he is protected from someone loggin in and running stuff
    >> as him. Password is required. Now, granted, it is not a good thing
    >> to give out yur password and is forbidden in many venue (like DOD) but
    >> I can think of and come up with places where this could still be used
    >> safely and would meet a need.

    >
    > I can think of no situation on VMS where sharing of passwords would be
    > reasonable (single user systems do not count, since there iws no sharing).


    As I said, where this was common at one time, today is different and
    many venue prohibit it. But I can remember a time, not all that long
    ago, when the VMS system here (not the one in my department, but the
    one run by the University Datacenter) had piles of "captive logins"
    that were used by numerous people who all shared a common password.
    Seemed to be the normal way of doing things on VMS.

    >
    > If you want to fully share access, then create usernames with a shared
    > UIC. They have the same rights to data but separate audit identities.


    If I am correct, that would be the same as a Unix Group. But that
    wasn't what the requestor was asking about. He wanted to run something
    as another user.

    bill

    --
    Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
    bill@cs.scranton.edu | and a sheep voting on what's for dinner.
    University of Scranton |
    Scranton, Pennsylvania | #include

  14. Re: SUBMIT command

    In article ,
    Kilgallen@SpamCop.net (Larry Kilgallen) writes:
    > In article <5o6l41Fktd8gU1@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:
    >> In article <4$VTv9Rz+Npg@eisner.encompasserve.org>,
    >> briggs@encompasserve.org writes:
    >>> In article <1193153254.512670.15500@t8g2000prg.googlegroups.co m>, a13365@yahoo.com writes:
    >>>> What kind privileges I need to check?
    >>>
    >>> $ HELP SUBMIT /USER
    >>> SUBMIT
    >>>
    >>> /USER
    >>>
    >>> /USER=username
    >>>
    >>> Requires CMKRNL (change mode to kernel) privilege and read (R)
    >>> and write (W) access to the user authorization file (UAF).

    >>
    >> Ohmigod!!!! There is actually something that Unix can do that
    >> VMS can't do (at least not without elevated priviledges on the
    >> VMS side!!)

    >
    > There are lots of things VMS considers to be security relevant
    > where Unix does not care.


    So you think requiring elevated proviledges is less of a security
    threat? Or is the VMS answer simply, "We won't let you do that."
    (Actually, that is the usual answer to any user request from the
    VMS shop here, so maybe it is the norm!!)


    bill

    --
    Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
    bill@cs.scranton.edu | and a sheep voting on what's for dinner.
    University of Scranton |
    Scranton, Pennsylvania | #include

  15. Re: unix "batch processing"

    bill@cs.uofs.edu (Bill Gunshannon) writes:

    > In article ,
    > Kilgallen@SpamCop.net (Larry Kilgallen) writes:


    >> If you want to fully share access, then create usernames with a shared
    >> UIC. They have the same rights to data but separate audit identities.


    > If I am correct, that would be the same as a Unix Group. But that
    > wasn't what the requestor was asking about. He wanted to run something
    > as another user.


    Not quite the same as a Unix group, which functions much like an RSX-11 or
    Tops-10 "project" (as in project-programmer number); I believe that VMS (used
    to) call UIC's by that name, too.

    The Unix equivalent to Mr. Kilgallen's suggestion is assigning the same numeric
    userid (uid) to two different usernames in the password file.

    --
    Rich Alderson "You get what anybody gets. You get a lifetime."
    news@alderson.users.panix.com --Death, of the Endless

  16. Re: SUBMIT command

    bill@cs.uofs.edu (Bill Gunshannon) writes:

    > In article ,
    > Kilgallen@SpamCop.net (Larry Kilgallen) writes:


    >> There are lots of things VMS considers to be security relevant
    >> where Unix does not care.


    > So you think requiring elevated proviledges is less of a security
    > threat?


    Of course, absent password sharing, "elevated privileges" is the way such
    things are done in a modern Unix as well.

    --
    Rich Alderson "You get what anybody gets. You get a lifetime."
    news@alderson.users.panix.com --Death, of the Endless

  17. Re: unix "batch processing"

    In article ,
    Rich Alderson writes:
    > bill@cs.uofs.edu (Bill Gunshannon) writes:
    >
    >> In article ,
    >> Kilgallen@SpamCop.net (Larry Kilgallen) writes:

    >
    >>> If you want to fully share access, then create usernames with a shared
    >>> UIC. They have the same rights to data but separate audit identities.

    >
    >> If I am correct, that would be the same as a Unix Group. But that
    >> wasn't what the requestor was asking about. He wanted to run something
    >> as another user.

    >
    > Not quite the same as a Unix group, which functions much like an RSX-11 or
    > Tops-10 "project" (as in project-programmer number); I believe that VMS (used
    > to) call UIC's by that name, too.
    >
    > The Unix equivalent to Mr. Kilgallen's suggestion is assigning the same numeric
    > userid (uid) to two different usernames in the password file.


    I certainly hope not as that would be an accounting nightmare and little
    different than sharing passwords. The only user that would ever show up
    is the first one (sequentially) in the password file. The only time the
    second (or subsequent) username (as opposed to uid) would be used is by
    the login process.

    VMS has UIDs and UICs (right?). The only equivalent in Unix would
    be uid and gid. Groups were never fully implemented (I beleive
    Dennis Ritchie has some papers ont he web somewhere explaining why)
    and as such do not offer the full capabilities you get with VMS UIC's.
    To be honest, like most of the questions of the type, "How do I do
    VMS function X under Unix?" It would probably be better if the asker
    just described what it was they were trying to accomplish with out
    couching it in terms of VMS and let someone who knows Unix give them
    a real answer. Of course, they should probably be asking it in a
    Unix newsgroup as well as the track record on Unix advice here has
    never been all that good.

    bill

    --
    Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
    bill@cs.scranton.edu | and a sheep voting on what's for dinner.
    University of Scranton |
    Scranton, Pennsylvania | #include

  18. Re: SUBMIT command

    In article ,
    Rich Alderson writes:
    > bill@cs.uofs.edu (Bill Gunshannon) writes:
    >
    >> In article ,
    >> Kilgallen@SpamCop.net (Larry Kilgallen) writes:

    >
    >>> There are lots of things VMS considers to be security relevant
    >>> where Unix does not care.

    >
    >> So you think requiring elevated proviledges is less of a security
    >> threat?

    >
    > Of course, absent password sharing, "elevated privileges" is the way such
    > things are done in a modern Unix as well.


    Ridiculous. As Unix only has two real levels of priviledge one
    would have to be an idiot to give a regular user elevated priviledges.
    Given a good, real explanation of the problem a true Unix solution not
    requiring elevated priviliedges could undoubtedly be found.

    bill


    --
    Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
    bill@cs.scranton.edu | and a sheep voting on what's for dinner.
    University of Scranton |
    Scranton, Pennsylvania | #include

  19. Re: SUBMIT command

    On Oct 23, 12:31 pm, b...@cs.uofs.edu (Bill Gunshannon) wrote:
    > In article ,
    > Kilgal...@SpamCop.net (Larry Kilgallen) writes:
    > > In article <5o6l41Fktd8...@mid.individual.net>, b...@cs.uofs.edu (Bill Gunshannon) writes:
    > >> In article <4$VTv9Rz+...@eisner.encompasserve.org>,
    > >> bri...@encompasserve.org writes:
    > >>> In article <1193153254.512670.15...@t8g2000prg.googlegroups.co m>, a13...@yahoo.com writes:
    > >>>> What kind privileges I need to check?

    >
    > >>> $ HELP SUBMIT /USER
    > >>> SUBMIT

    >
    > >>> /USER

    >
    > >>> /USER=username

    >
    > >>> Requires CMKRNL (change mode to kernel) privilege and read (R)
    > >>> and write (W) access to the user authorization file (UAF).

    >
    > >> Ohmigod!!!! There is actually something that Unix can do that
    > >> VMS can't do (at least not without elevated priviledges on the
    > >> VMS side!!)

    >
    > > There are lots of things VMS considers to be security relevant
    > > where Unix does not care.

    >
    > So you think requiring elevated proviledges is less of a security
    > threat?


    Absolutely! To run a job as another user on VMS, you must be
    authorized to do so. Apparently on *nix, you just need to know a
    password. On any pass-word protected system, anyone who knows a user's
    password can log in as that user. Is that "built-in" security?

    > Or is the VMS answer simply, "We won't let you do that."
    > (Actually, that is the usual answer to any user request from the
    > VMS shop here, so maybe it is the norm!!)
    >


    The OP question of "how" needs an answer to the question of "why." If
    user "notscott" needs to submit a job as "scott" then I'd say there's
    something wrong with the site's security model. VMS offers many ways
    to achieve any such legitimate result without using impersonation. I
    have never found a sound reason for one user to impersonate another in
    a production environment except at the administration level.

    A person must be authorized to do something or "we won't let them do
    that" and that's the way it should be. How can anyone interested in
    keeping a secure system find fault with that?

    Maybe the OP found a scott-owned batch job that scott claims he didn't
    submit? We don't know because the question of what problem the OP is
    trying to solve hasn't been answered.


  20. Re: SUBMIT command

    Doug Phillips wrote:
    > Absolutely! To run a job as another user on VMS, you must be
    > authorized to do so.



    Are there not any remnants of the punched card days where you could
    specify username/password to create a batch job running under that user
    ? (is it the $DECK stuff ?)

    Of course, you can use DECNET to create a task under any
    username/password combo. eg: NODE"user pass"::"0=TEST"

+ Reply to Thread
Page 1 of 5 1 2 3 ... LastLast