[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: LSB specification for adding users and groups



> On Wed, 16 Jun 1999, Galen Hancock wrote:
> > I don't think that would be enough, because new files with the old
> > [ug]ids could be created while find is running. Some programs could be
> > running that rely on the numbers as they existed when they started.
> > (Some programs could even have uids compiled into them.)

On Wed, Jun 16, 1999 at 06:17:26PM -0700, Tonnesen Steve wrote:
> If you change the passwd/group files before running the find, this
> wouldn't be a problem.  It could cause some havoc if mail programs (for
> example) couldn't access their files for the few minutes it takes to run
> the find though.  Stopping MTAs before running the find might alleviate
> that problem.

A mail server could be running with gid mail, and be creating files.
There is nothing that says they have to keep looking their number up in
the passwd/group file each time they access a file (and if it follows
good practice, it might well have dropped the ability to change its
[ug]id completely at this point). Such a program wouldn't just be unable
to access its files for a "few minutes", it would be unable to access
its files anymore, period.

As you say, MTAs should be stopped. Everything that is running that
needs to use the password information should be stopped. I really
wouldn't do this sort of thing without taking the system down into
single-user mode first.

> Someone else mentioned that running chown will strip the set[ug]id bit.
> This didn't happen when I tried it.  Is it supposed to?

I think it should :-), but it doesn't.

> Is there a good reason why a program would use a uid instead of a uname?

It makes sense to only look up a uid once, at the beginning of a
program, than to keep looking it up.

					Galen

-- 
Ambiguous cases are defined as those for which the compiler being used finds a
legitimate interpretation which is different from that which the user had in
mind.
			--The INTERCAL Programming Language Reference Manual


Reply to: