Any race conditions involved on adding/mod users from differentprocesses - Linux

This is a discussion on Any race conditions involved on adding/mod users from differentprocesses - Linux ; Hi, If I am adding or modifying users -useradd,usermod(entries in /etc/ passwd) simultaneously from different processes, Is it safe to do that ?. Does linux internally take care of all race conditions ? Thanks Reji Thomas...

+ Reply to Thread
Results 1 to 18 of 18

Thread: Any race conditions involved on adding/mod users from differentprocesses

  1. Any race conditions involved on adding/mod users from differentprocesses

    Hi,

    If I am adding or modifying users -useradd,usermod(entries in /etc/
    passwd) simultaneously from different processes, Is it safe to do
    that ?. Does linux internally take care of all race conditions ?

    Thanks
    Reji Thomas

  2. Re: Any race conditions involved on adding/mod users from differentprocesses

    On Jun 18, 2:57 am, Reji wrote:
    > Hi,
    >
    > If I am adding or modifying users -useradd,usermod(entries in /etc/
    > passwd) simultaneously from different processes, Is it safe to do
    > that ?. Does linux internally take care of all race conditions ?
    >
    > Thanks
    > Reji Thomas


    No and No.

    This would seem to be an unsafe practice just based on the fact you
    have processes adding users to the system. Once one of those processes
    is hacked, someone will be able to hijack your system completely. I
    think you have a really poor design, security-wise. And you have the
    race conditions as well. Time to reconsider your plan.
    Ed

  3. Re: Any race conditions involved on adding/mod users from differentprocesses

    On Jun 18, 4:38 pm, Ed Prochak wrote:
    > On Jun 18, 2:57 am, Reji wrote:
    >
    > > Hi,

    >
    > > If I am adding or modifying users -useradd,usermod(entries in /etc/
    > > passwd) simultaneously from different processes, Is it safe to do
    > > that ?. Does linux internally take care of all race conditions ?

    >
    > > Thanks
    > > Reji Thomas

    >
    > No and No.
    >
    > This would seem to be an unsafe practice just based on the fact you
    > have processes adding users to the system. Once one of those processes
    > is hacked, someone will be able to hijack your system completely. I
    > think you have a really poor design, security-wise. And you have the
    > race conditions as well. Time to reconsider your plan.
    > Ed


    wrt race condition, do you mean to say that usermod/useradd functions
    dont really lock the file( which I feel is highly uncertain)?, Looks
    like I will do a browse of source code.
    btw its to do with virtual systems running on top of linux os and
    security is very much taken care in the design

  4. Re: Any race conditions involved on adding/mod users from different processes

    Reji wrote:

    > On Jun 18, 4:38 pm, Ed Prochak wrote:
    >> On Jun 18, 2:57 am, Reji wrote:


    >> > If I am adding or modifying users -useradd,usermod(entries in /etc/
    >> > passwd) simultaneously from different processes, Is it safe to do
    >> > that ?. Does linux internally take care of all race conditions ?


    >> No and No.


    > wrt race condition, do you mean to say that usermod/useradd functions
    > dont really lock the file( which I feel is highly uncertain)?, Looks
    > like I will do a browse of source code.


    Suppose you read the code for usermod and useradd, and you find that
    they perform some kind of advisory locking. This does not prevent other
    processes from ignoring those advisory locks (or not being aware of
    them) and modifying /etc/passwd asynchronously, thus creating a race
    condition.

    Even just a user logged in as root can use vi to edit the file without
    regard to the locks.
    --
    Fran

  5. Re: Any race conditions involved on adding/mod users from differentprocesses

    On Jun 18, 12:20*pm, Francis Litterio wrote:

    > Suppose you read the code for usermod and useradd, and you find that
    > they perform some kind of advisory locking. *This does not prevent other
    > processes from ignoring those advisory locks (or not being aware of
    > them) and modifying /etc/passwd asynchronously, thus creating a race
    > condition.


    > Even just a user logged in as root can use vi to edit the file without
    > regard to the locks.


    Of course, but then that something else would be causing a problem.
    He's not trying to fix the whole world.

    DS

  6. Re: Any race conditions involved on adding/mod users from differentprocesses

    On Jun 19, 3:42 am, David Schwartz wrote:
    > On Jun 18, 12:20 pm, Francis Litterio wrote:
    >
    > > Suppose you read the code for usermod and useradd, and you find that
    > > they perform some kind of advisory locking. This does not prevent other
    > > processes from ignoring those advisory locks (or not being aware of
    > > them) and modifying /etc/passwd asynchronously, thus creating a race
    > > condition.
    > > Even just a user logged in as root can use vi to edit the file without
    > > regard to the locks.

    >
    > Of course, but then that something else would be causing a problem.
    > He's not trying to fix the whole world.
    >
    > DS



    Dont you think this is the same scenario as trying to do useradd/
    usermod from multiple sessions to linux box at the same time. The
    shell process is going to be different and so if the program doesnt
    take care of such a situation the system will end up in a mess.
    I feel this shouldnt cause an issue. If I am getting something wrong
    please let me know.

    Thanks
    Reji

  7. Re: Any race conditions involved on adding/mod users from different processes

    Reji writes:
    > On Jun 19, 3:42 am, David Schwartz wrote:
    >> On Jun 18, 12:20 pm, Francis Litterio wrote:
    >> > Suppose you read the code for usermod and useradd, and you find that
    >> > they perform some kind of advisory locking. This does not prevent other
    >> > processes from ignoring those advisory locks (or not being aware of
    >> > them) and modifying /etc/passwd asynchronously, thus creating a race
    >> > condition.
    >> > Even just a user logged in as root can use vi to edit the file without
    >> > regard to the locks.

    >>
    >> Of course, but then that something else would be causing a problem.
    >> He's not trying to fix the whole world.

    >
    >
    > Dont you think this is the same scenario as trying to do useradd/
    > usermod from multiple sessions to linux box at the same time.


    No, it is not. 'vi' is a text editor and has no knowledge of the
    "purposes" of the files edited with it. Consequently, it cannot obey
    to any specific locking protocol used by a set of related applications
    to coordinate their accesses to 'some shared ressources' [files]. This
    is a fundamental difference to Windows, where file locks are (IIRC)
    always mandatory, ie the contraints associated with them are enforced
    by the OS. (Usual) UNIX(*) file locking is advisory and meant to be
    used among cooperating applications only.

  8. Re: Any race conditions involved on adding/mod users from different processes

    Rainer Weikusat writes:
    > No, it is not. 'vi' is a text editor and has no knowledge of the
    > "purposes" of the files edited with it. Consequently, it cannot obey to
    > any specific locking protocol used by a set of related applications to
    > coordinate their accesses to 'some shared ressources' [files].


    That's what vipw is for.
    --
    John Hasler
    john@dhh.gt.org
    Dancing Horse Hill
    Elmwood, WI USA

  9. Re: Any race conditions involved on adding/mod users from different processes

    John Hasler writes:
    > Rainer Weikusat writes:
    >> No, it is not. 'vi' is a text editor and has no knowledge of the
    >> "purposes" of the files edited with it. Consequently, it cannot obey to
    >> any specific locking protocol used by a set of related applications to
    >> coordinate their accesses to 'some shared ressources' [files].

    >
    > That's what vipw is for.


    The the shadow password suit includes a 'frontend' calling $VISUAL (or
    $EDITOR) in the 'proper' way for interacting with the other tools (eg
    usermod) being part of it in no way affects any particular editor
    itself (or any other program not being part of this package).


  10. Re: Any race conditions involved on adding/mod users from different processes

    Rainer Weikusat wrote:
    > John Hasler writes:
    >> Rainer Weikusat writes:
    >>> No, it is not. 'vi' is a text editor and has no knowledge of the
    >>> "purposes" of the files edited with it. Consequently, it cannot obey to
    >>> any specific locking protocol used by a set of related applications to
    >>> coordinate their accesses to 'some shared ressources' [files].

    >>
    >> That's what vipw is for.

    >
    > The the shadow password suit includes a 'frontend' calling $VISUAL (or
    > $EDITOR) in the 'proper' way for interacting with the other tools (eg
    > usermod) being part of it in no way affects any particular editor
    > itself (or any other program not being part of this package).
    >

    Unless, of course, they follow the same conventions as vipw. IIRC vipw
    creates a copy of the file which serves as a lock file.

    Jerry

  11. Re: Any race conditions involved on adding/mod users from differentprocesses

    On Jun 20, 1:53 am, Jerry Peters wrote:
    > Rainer Weikusat wrote:
    > > John Hasler writes:
    > >> Rainer Weikusat writes:
    > >>> No, it is not. 'vi' is a text editor and has no knowledge of the
    > >>> "purposes" of the files edited with it. Consequently, it cannot obey to
    > >>> any specific locking protocol used by a set of related applications to
    > >>> coordinate their accesses to 'some shared ressources' [files].

    >
    > >> That's what vipw is for.

    >
    > > The the shadow password suit includes a 'frontend' calling $VISUAL (or
    > > $EDITOR) in the 'proper' way for interacting with the other tools (eg
    > > usermod) being part of it in no way affects any particular editor
    > > itself (or any other program not being part of this package).

    >
    > Unless, of course, they follow the same conventions as vipw. IIRC vipw
    > creates a copy of the file which serves as a lock file.
    >
    > Jerry



    I feel my question was not clear. I was not asking about someone
    modifying /etc/passwd using a editor or anything else
    but only using linux specified commands or library apis.


    Thanks
    Reji

  12. Re: Any race conditions involved on adding/mod users from different processes

    Jerry Peters writes:
    > Rainer Weikusat wrote:
    >> John Hasler writes:
    >>> Rainer Weikusat writes:
    >>>> No, it is not. 'vi' is a text editor and has no knowledge of the
    >>>> "purposes" of the files edited with it. Consequently, it cannot obey to
    >>>> any specific locking protocol used by a set of related applications to
    >>>> coordinate their accesses to 'some shared ressources' [files].
    >>>
    >>> That's what vipw is for.

    >>
    >> The the shadow password suit includes a 'frontend' calling $VISUAL (or
    >> $EDITOR) in the 'proper' way for interacting with the other tools (eg
    >> usermod) being part of it in no way affects any particular editor
    >> itself (or any other program not being part of this package).
    >>

    > Unless, of course, they follow the same conventions as vipw.


    That would not be a cause-and-effect-relation.


  13. Re: Any race conditions involved on adding/mod users from different processes

    Reji writes:
    > On Jun 20, 1:53 am, Jerry Peters wrote:
    >> Rainer Weikusat wrote:
    >> > John Hasler writes:
    >> >> Rainer Weikusat writes:
    >> >>> No, it is not. 'vi' is a text editor and has no knowledge of the
    >> >>> "purposes" of the files edited with it. Consequently, it cannot obey to
    >> >>> any specific locking protocol used by a set of related applications to
    >> >>> coordinate their accesses to 'some shared ressources' [files].

    >>
    >> >> That's what vipw is for.

    >>
    >> > The the shadow password suit includes a 'frontend' calling $VISUAL (or
    >> > $EDITOR) in the 'proper' way for interacting with the other tools (eg
    >> > usermod) being part of it in no way affects any particular editor
    >> > itself (or any other program not being part of this package).

    >>
    >> Unless, of course, they follow the same conventions as vipw. IIRC vipw
    >> creates a copy of the file which serves as a lock file.


    [...]

    > I feel my question was not clear. I was not asking about someone
    > modifying /etc/passwd using a editor or anything else
    > but only using linux specified commands or library apis.


    You seem to have trouble understanding that there are no 'Linux
    commands or library APIs' for doing this. Various tools exist to help
    with manageing user accounts, but these exist for convenience only,
    not because there would be a technical requirement to use them.

    The shadow password package includes a couple of them and these take
    care of proper interlocking among each other. Other tools may or may
    not and in the end, what is actually happening is that certain files
    are modified. Eg, it is possible to create a poor man's
    single-sign-on-system by running rsync from cron. A variety of methods
    exists to support more centralized management of user accounts for
    sets of computers.

  14. Re: Any race conditions involved on adding/mod users from differentprocesses

    Hi,

    In article ,
    Reji wrote:
    >On Jun 20, 1:53 am, Jerry Peters wrote:

    [....]
    >I feel my question was not clear. I was not asking about someone
    >modifying /etc/passwd using a editor or anything else
    >but only using linux specified commands or library apis.


    please try it yourself:
    open passwd with vipw and then try useradd or usermod. They will
    wait until the lock is released.

    That should be enough for your needs. And yes, root can ignore the lock
    and do something like 'rm -f /etc/passwd' behind your sript. But thats
    a completely different problem ;-))

    regards

    winfried

    --
    Winfried Magerl - Internet Administration
    Siemens IT Solutions and Services, 81739 Munich, Germany
    Internet-Mail: winfried.magerl@siemens.com

  15. Re: Any race conditions involved on adding/mod users from different ?processes

    Reji wrote:
    > On Jun 20, 1:53 am, Jerry Peters wrote:
    >> Rainer Weikusat wrote:
    >> > John Hasler writes:
    >> >> Rainer Weikusat writes:
    >> >>> No, it is not. 'vi' is a text editor and has no knowledge of the
    >> >>> "purposes" of the files edited with it. Consequently, it cannot obey to
    >> >>> any specific locking protocol used by a set of related applications to
    >> >>> coordinate their accesses to 'some shared ressources' [files].

    >>
    >> >> That's what vipw is for.

    >>
    >> > The the shadow password suit includes a 'frontend' calling $VISUAL (or
    >> > $EDITOR) in the 'proper' way for interacting with the other tools (eg
    >> > usermod) being part of it in no way affects any particular editor
    >> > itself (or any other program not being part of this package).

    >>
    >> Unless, of course, they follow the same conventions as vipw. IIRC vipw
    >> creates a copy of the file which serves as a lock file.
    >>
    >> Jerry

    >
    >
    > I feel my question was not clear. I was not asking about someone
    > modifying /etc/passwd using a editor or anything else
    > but only using linux specified commands or library apis.
    >
    >
    > Thanks
    > Reji


    No, you've been asking about useradd and usermod which are
    _application_ programs to manage user accounts. Any locking is the
    responsibility of the application.
    BTW this is OSS, why not just examine the code for user* or even
    strace the process?

    Jerry

  16. Re: Any race conditions involved on adding/mod users from different ?processes

    Jerry Peters writes:

    [...]

    > No, you've been asking about useradd and usermod which are
    > _application_ programs to manage user accounts. Any locking is the
    > responsibility of the application. BTW this is OSS, why not just
    > examine the code for user* or even
    > strace the process?


    The shadow password programs still use a suitable locking protocol
    among themselves.

  17. Re: Any race conditions involved on adding/mod users from different ?processes

    Rainer Weikusat wrote:
    > Jerry Peters writes:
    >
    > [...]
    >
    >> No, you've been asking about useradd and usermod which are
    >> _application_ programs to manage user accounts. Any locking is the
    >> responsibility of the application. BTW this is OSS, why not just
    >> examine the code for user* or even
    >> strace the process?

    >
    > The shadow password programs still use a suitable locking protocol
    > among themselves.


    Yes, that's what I would assume, but I don't care enough to actually
    look. I'm guessing the OP comes from some proprietary, closed source
    environment.

    Jerry

  18. Re: Any race conditions involved on adding/mod users from different ?processes

    Jerry Peters writes:
    > Rainer Weikusat wrote:
    >> Jerry Peters writes:
    >>
    >> [...]
    >>
    >>> No, you've been asking about useradd and usermod which are
    >>> _application_ programs to manage user accounts. Any locking is the
    >>> responsibility of the application. BTW this is OSS, why not just
    >>> examine the code for user* or even
    >>> strace the process?

    >>
    >> The shadow password programs still use a suitable locking protocol
    >> among themselves.

    >
    > Yes, that's what I would assume, but I don't care enough to actually
    > look.


    I did.

+ Reply to Thread