Any race conditions involved on adding/mod users from different processes
Reji
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
Ed Prochak
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
Reji
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 :)
Francis Litterio
> 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
David Schwartz
> 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
Reji
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
Rainer Weikusat
> On Jun 19, 3:42 am, David Schwartz <dav...@webmaster.com> wrote:
>> On Jun 18, 12:20 pm, Francis Litterio <em...@not.available> 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.
>
>
> 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.
John Hasler
> 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
jo...@dhh.gt.org
Dancing Horse Hill
Elmwood, WI USA
Rainer Weikusat
> 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).
Jerry Peters
creates a copy of the file which serves as a lock file.
Jerry
Reji
> Rainer Weikusat <rweiku...@mssgmbh.com> 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.
Thanks
Reji
Rainer Weikusat
That would not be a cause-and-effect-relation.
Rainer Weikusat
> On Jun 20, 1:53 am, Jerry Peters <je...@example.invalid> wrote:
>> Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
>> > John Hasler <j...@dhh.gt.org> 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.
Winfried Magerl
In article <ad1a39e8-6170-44cf...@z16g2000prn.googlegroups.com>,
Reji <rejith...@gmail.com> wrote:
>On Jun 20, 1:53 am, Jerry Peters <je...@example.invalid> 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: winfrie...@siemens.com
Jerry Peters
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
Rainer Weikusat
[...]
> 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.
Jerry Peters
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
Rainer Weikusat
> Rainer Weikusat <rwei...@mssgmbh.com> wrote:
>> Jerry Peters <je...@example.invalid> 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.