SUBMIT command - VMS

This is a discussion on SUBMIT command - VMS ; On 10/23/07 11:17, Bill Gunshannon wrote: > In article , > briggs@encompasserve.org writes: >> In article , a13365@yahoo.com writes: >>> What kind privileges I need to check? >> $ HELP SUBMIT /USER >> SUBMIT >> >> /USER >> >> /USER=username ...

+ Reply to Thread
Page 2 of 5 FirstFirst 1 2 3 4 ... LastLast
Results 21 to 40 of 87

Thread: SUBMIT command

  1. Re: SUBMIT command

    On 10/23/07 11:17, Bill Gunshannon wrote:
    > In article <4$VTv9Rz+Npg@eisner.encompasserve.org>,
    > briggs@encompasserve.org writes:
    >> In article , 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!!)


    It would be kinda awkward for a batch job to prompt for a password.

    Anyway, submitting a job under some other meatbag's username is
    frowned upon at our site.

    --
    Ron Johnson, Jr.
    Jefferson LA USA

    Give a man a fish, and he eats for a day.
    Hit him with a fish, and he goes away for good!

  2. Re: SUBMIT command

    On 10/23/07 13:35, Rich Alderson wrote:
    > 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.


    sudo and /etc/sudoers.

    The sysadmin gives specific users specific permission to run
    specific programs.

    --
    Ron Johnson, Jr.
    Jefferson LA USA

    Give a man a fish, and he eats for a day.
    Hit him with a fish, and he goes away for good!

  3. Re: SUBMIT command

    On Oct 23, 3:21 pm, JF Mezei wrote:
    > 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"



    Don't know. All of my punched card days (with one brief exception)
    were spent with IBM mainframes.

    A punched card type of batch process would probably not be run by a
    "normal" user, though, but by an operator with priv's sufficient to
    operate the system or be submitted by a system-like account. If the
    batch mechanism you mention (not the DECnet stuff -- that's different)
    still exists, I've never seen nor used it. A "normal" user should
    never have a reason to do *anything* under another user's name or to
    know another user's password in order to do their own work. Period.

    One of the really great things about VMS is that you can do pretty
    much anything you want, security wise. You can open up or restrict it
    however and as much as you want or need to. In other words, with VMS
    you have all of the choices. You can run with zero to near-maximum
    security and anywhere between by using the tools that come with it.
    You aren't forced to compensate or make compromises. You just need to
    understand the tools.

    Since I don't work with any "modern" *nix/*nux in anything other than
    a play-toy environment, I don't know all of its security tricks,
    strengths or weaknesses, so I won't enter into that war. Heck, even
    after all these years I'm still learning things about VMS!


  4. Re: SUBMIT command

    In article , Ron Johnson writes:
    >
    >
    >On 10/23/07 13:35, Rich Alderson wrote:
    >> 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.

    >
    >sudo and /etc/sudoers.
    >
    >The sysadmin gives specific users specific permission to run
    >specific programs.



    I only wish that I could enter 'sudo' and type my password and then
    stay in a context where I could do multiple commands with the 'sudo'
    authorized privies.

    i.e.

    % sudo
    Password: ******
    sudo% command
    sudo% command
    sudo% command
    sudo% exit


    --
    VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM

    "Well my son, life is like a beanstalk, isn't it?"

    http://tmesis.com/drat.html

  5. Re: SUBMIT command

    In article ,
    VAXman- @SendSpamHere.ORG writes:
    > In article , Ron Johnson writes:
    >>
    >>
    >>On 10/23/07 13:35, Rich Alderson wrote:
    >>> 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.

    >>
    >>sudo and /etc/sudoers.
    >>
    >>The sysadmin gives specific users specific permission to run
    >>specific programs.

    >
    >
    > I only wish that I could enter 'sudo' and type my password and then
    > stay in a context where I could do multiple commands with the 'sudo'
    > authorized privies.
    >
    > i.e.
    >
    > % sudo
    > Password: ******
    > sudo% command
    > sudo% command
    > sudo% command
    > sudo% exit


    Well, sudo is for specific commands and not general use. But it
    wouldn't take much to provide a menu that had more than one command
    available at any given time. If you are looking for general command
    execution use plain "su".

    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

  6. Re: SUBMIT command

    On Tue, 23 Oct 2007 VAXman-@SendSpamHere.ORG wrote:

    > I only wish that I could enter 'sudo' and type my password and then
    > stay in a context where I could do multiple commands with the 'sudo'
    > authorized privies.
    >
    > i.e.
    >
    > % sudo
    > Password: ******
    > sudo% command
    > sudo% command
    > sudo% command
    > sudo% exit


    On my system, "sudo -s" does that. I think, however, that none of the
    subsequent commands are logged like they would have been if you had
    done "sudo command".


    --

    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/


  7. Re: SUBMIT command

    In article <1193168826.737884.26220@v29g2000prd.googlegroups.c om>,
    Doug Phillips writes:
    > 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."


    That's why I said more info was needed in order to devise a suitable
    and secure method to accomplish it.

    > 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.
    >


    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

  8. [OT] sudo (was:Re: SUBMIT command)

    VAXman- @SendSpamHere.ORG wrote:
    > In article , Ron Johnson writes:

    [...]
    > I only wish that I could enter 'sudo' and type my password and then
    > stay in a context where I could do multiple commands with the 'sudo'
    > authorized privies.
    >
    > i.e.
    >
    > % sudo
    > Password: ******
    > sudo% command
    > sudo% command
    > sudo% command
    > sudo% exit


    On the Linux distro I use on my laptop (Ubuntu), I think that sudo is
    "timeout-controlled"; i.e., I can enter several "sudo" commands in quick
    succession without re-entering the password each time, but if I wait for
    a(n) (unknown) period of time, I have to enter a password on the
    subsequent "sudo" command.

  9. Re: SUBMIT command

    On Tue, 23 Oct 2007, JF Mezei wrote:

    > 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 ?)


    According to the System Manager's Guide and the DCL Dictionary, you
    need a $JOB card to specify the username and a $PASSWORD card to
    specify the password.


    --

    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/


  10. Re: [OT] sudo

    On 10/23/07 18:32, bradhamilton wrote:
    > VAXman- @SendSpamHere.ORG wrote:
    >> In article , Ron Johnson
    >> writes:

    > [...]
    >> I only wish that I could enter 'sudo' and type my password and then
    >> stay in a context where I could do multiple commands with the 'sudo'
    >> authorized privies.
    >> i.e.
    >>
    >> % sudo
    >> Password: ******
    >> sudo% command
    >> sudo% command
    >> sudo% command
    >> sudo% exit

    >
    > On the Linux distro I use on my laptop (Ubuntu), I think that sudo is
    > "timeout-controlled"; i.e., I can enter several "sudo" commands in quick
    > succession without re-entering the password each time, but if I wait for
    > a(n) (unknown) period of time, I have to enter a password on the
    > subsequent "sudo" command.


    $ man 5 sudoers
    Number of minutes that can elapse before sudo will ask for
    a passwd again. The default is 15. Set this to 0 to always
    prompt for a password. If set to a value less than 0 the
    user's timestamp will never expire. This can be used to
    allow users to create or delete their own timestamps via
    sudo -v and sudo -k respectively.

    --
    Ron Johnson, Jr.
    Jefferson LA USA

    Give a man a fish, and he eats for a day.
    Hit him with a fish, and he goes away for good!

  11. Re: SUBMIT command

    On 10/23/07 17:31, Doug Phillips wrote:
    [snip]
    >
    > Don't know. All of my punched card days (with one brief exception)
    > were spent with IBM mainframes.
    >
    > A punched card type of batch process would probably not be run by a
    > "normal" user, though, but by an operator with priv's sufficient to
    > operate the system or be submitted by a system-like account. If the


    But all batch jobs are "punched card type of batch process", since a
    ..COM file is a pseudo-deck.

    --
    Ron Johnson, Jr.
    Jefferson LA USA

    Give a man a fish, and he eats for a day.
    Hit him with a fish, and he goes away for good!

  12. Re: SUBMIT command

    Ron Johnson wrote:
    > But all batch jobs are "punched card type of batch process", since a
    > .COM file is a pseudo-deck.
    >


    On MVS (or whatever it is called this week), this is the case. But on
    VMS, this is not quite the case.

    On VMS, a batch entry is a glorified pointer to a file. So when a batch
    job starts, it reads from that file.

    I have to assume that for VMS "punched card" stuff, there would have
    been some detached process controlling the hardware reader and it was
    that detached process that would have copied the cards to some temporary
    files that would have then been submitted. (is that correct ?)

  13. Re: SUBMIT command

    On 10/23/07 21:25, JF Mezei wrote:
    > Ron Johnson wrote:
    >> But all batch jobs are "punched card type of batch process", since a
    >> .COM file is a pseudo-deck.
    >>

    >
    > On MVS (or whatever it is called this week), this is the case. But on
    > VMS, this is not quite the case.
    >
    > On VMS, a batch entry is a glorified pointer to a file. So when a batch
    > job starts, it reads from that file.
    >
    > I have to assume that for VMS "punched card" stuff, there would have
    > been some detached process controlling the hardware reader and it was
    > that detached process that would have copied the cards to some temporary
    > files that would have then been submitted. (is that correct ?)


    OTOH, the $ that leads all "command" lines serves the same function
    as JCL's //, and data rows act just like they do in a card deck.

    $ SET VER
    $ RUN SYS$LOGIN:SOMEPROG.EXE
    DATA 1
    MORE DATA
    LOTS OF DATA
    EVEN MORE DATA
    $! END OF STREAM
    $ EXIT

    If it looks like a deck, acts like a deck and quacks like a deck,
    it's a card deck.

    --
    Ron Johnson, Jr.
    Jefferson LA USA

    Give a man a fish, and he eats for a day.
    Hit him with a fish, and he goes away for good!

  14. Re: [OT] sudo (was:Re: SUBMIT command)

    In article <471E8477.1070802@comcast.net>,
    bradhamilton wrote:

    > VAXman- @SendSpamHere.ORG wrote:
    > > In article , Ron Johnson
    > > writes:

    > [...]
    > > I only wish that I could enter 'sudo' and type my password and then
    > > stay in a context where I could do multiple commands with the 'sudo'
    > > authorized privies.
    > >
    > > i.e.
    > >
    > > % sudo
    > > Password: ******
    > > sudo% command
    > > sudo% command
    > > sudo% command
    > > sudo% exit

    >
    > On the Linux distro I use on my laptop (Ubuntu), I think that sudo is
    > "timeout-controlled"; i.e., I can enter several "sudo" commands in quick
    > succession without re-entering the password each time, but if I wait for
    > a(n) (unknown) period of time, I have to enter a password on the
    > subsequent "sudo" command.


    Ditto on OS X. From 'man sudo':

    "Once a user has been authenticated, a timestamp is updated and the
    user may then use sudo without a password for a short period of time
    (5 minutes unless overridden in sudoers)."

    There is also 'sudo -k' which cancels the above timestamp, so that you
    can do:

    sudo command1
    Password: ******
    sudo command2
    sudo command3
    sudo -k # kill the sudo timestamp
    sudo command4
    Password: ******

    --
    Paul Sture

    Sue's OpenVMS bookmarks:
    http://eisner.encompasserve.org/~stu...bookmarks.html

  15. Re: SUBMIT command

    Ron Johnson wrote:

    >
    > If it looks like a deck, acts like a deck and quacks like a deck,
    > it's a card deck.
    >


    Yes, but on MVS/zOS/whatever it is still a little different.
    In the beginning the mainframes had mainly card-readers (input)
    and lineprinters (output) devices. That's it. The MVS kernel
    only understands 80 char record oriented input (card decks)
    and 132 char output (lineprinters). Everything else is just
    an emulation put on top of that, some one once said. :-)

    When you've edited a dataset with your JCL commands in TSO/ISPF,
    and enter the SUBmit command to run it, it is actualy written
    to the "internal reader", which is an emulated card reader
    making the MVS kernel think that you've actualy put some
    cards in a physical reader...

    I'm not sure if VMS still have something like that "inside".

    Jan-Erik.

  16. Re: SUBMIT command

    Ron Johnson wrote:
    > If it looks like a deck, acts like a deck and quacks like a deck,
    > it's a card deck.


    The big difference is that in MVS, when you submit a job (print or
    batch), the actual data is spooled to some area. (aka: a copy of your
    data is sent to the batch/print engine).

    With VMS, only a pointer to the file is sent. When the job is processed,
    the engine accesses your original file. If you have modified the actual
    file between the submit and the time it executes, your modified file is
    used. ( the queueing system keeps track of files by file-id, so you need
    to edit files "in-situ) for this to work).

  17. Re: SUBMIT command

    In article <5o7d9lFkmdm3U1@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:
    {...snip...}
    >Well, sudo is for specific commands and not general use. But it
    >wouldn't take much to provide a menu that had more than one command
    >available at any given time. If you are looking for general command
    >execution use plain "su".


    But that would mean handing out the root password to sudoers. Where's
    the security in that?

    --
    VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM

    "Well my son, life is like a beanstalk, isn't it?"

    http://tmesis.com/drat.html

  18. Re: SUBMIT command

    In article , Rob Brown writes:
    >
    >
    >On Tue, 23 Oct 2007 VAXman-@SendSpamHere.ORG wrote:
    >
    >> I only wish that I could enter 'sudo' and type my password and then
    >> stay in a context where I could do multiple commands with the 'sudo'
    >> authorized privies.
    >>
    >> i.e.
    >>
    >> % sudo
    >> Password: ******
    >> sudo% command
    >> sudo% command
    >> sudo% command
    >> sudo% exit

    >
    >On my system, "sudo -s" does that. I think, however, that none of the
    >subsequent commands are logged like they would have been if you had
    >done "sudo command".


    Thanks. I'll try that later.

    --
    VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM

    "Well my son, life is like a beanstalk, isn't it?"

    http://tmesis.com/drat.html

  19. Re: SUBMIT command

    In article <4de54$471e57db$cef8887a$17324@TEKSAVVY.COM>, JF Mezei writes:
    > 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 ?)


    $ help job
    JOB

    Identifies the beginning of a batch job submitted through a card
    reader. Each batch job submitted through the system card reader
    must be preceded by a JOB card.

    JOB cannot be abbreviated.

    Format

    JOB user-name
    [...]

    $ help password

    PASSWORD

    Provides the password associated with the user name that you
    specify with the JOB card when you submit a batch job through a
    card reader. Although the PASSWORD card is required, the password
    on the card is optional if the account has a null password.

  20. Re: SUBMIT command

    JF Mezei wrote:
    > Ron Johnson wrote:
    >
    >> If it looks like a deck, acts like a deck and quacks like a deck,
    >> it's a card deck.

    >
    >
    > The big difference is that in MVS, when you submit a job (print or
    > batch), the actual data is spooled to some area. (aka: a copy of your
    > data is sent to the batch/print engine).
    >
    > With VMS, only a pointer to the file is sent. When the job is processed,
    > the engine accesses your original file. If you have modified the actual
    > file between the submit and the time it executes, your modified file is
    > used. ( the queueing system keeps track of files by file-id, so you need
    > to edit files "in-situ) for this to work).


    That is bull****! When you submit a job, the command file you submit is
    executed. If that file no longer exists, the job fails. The system
    keeps track by File ID. I suppose it is POSSIBLE to modify the file
    without creating a new version but you would really have to work at it.


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