On Fri, Feb 16, 2007 at 10:45:53AM +1100, Brian May wrote:
> I suspect you will find it behaves in much the same way on all Unix
> like operating systems, unless caching is used or /etc/passwd has been
> replaced with a db file or database (do any OS do this by default?).
We've used nscd on Solar
On Fri, Feb 16, 2007 at 10:45:53AM +1100, Brian May wrote:
> > "Pierre" == Pierre Habouzit <[EMAIL PROTECTED]> writes:
>
> Pierre> I totally agree with that. the _gnu libc_ getpwuid
> Pierre> implementation is nothing, even not a de facto
> Pierre> standard. I'm almost sure it do
> "Pierre" == Pierre Habouzit <[EMAIL PROTECTED]> writes:
Pierre> I totally agree with that. the _gnu libc_ getpwuid
Pierre> implementation is nothing, even not a de facto
Pierre> standard. I'm almost sure it does not behave the same on
Pierre> other OS'es.
I suspect you wil
tag 411059 + wontfix
severity 411059 wishlist
thanks
On Thu, Feb 15, 2007 at 12:51:12PM -0800, Steve Langasek wrote:
> On Thu, Feb 15, 2007 at 03:47:53PM +, Ian Jackson wrote:
> > Steve Langasek writes ("Re: recent etch upgrade... sashroot (uid=0) started
> > to imp
On Thu, Feb 15, 2007 at 03:47:53PM +, Ian Jackson wrote:
> Steve Langasek writes ("Re: recent etch upgrade... sashroot (uid=0) started
> to impersonate uid=0 (root)"):
> > Again, I believe the behavior is not a bug because the behavior of
> > getpwuid() when two
clone 410758 -1
reassign -1 nscd
retitle -1 nscd: getpwuid() behavior differs from default (de-facto standard)
severity -1 normal
thanks
> > This behavior is related to other nscd issues in the past that /were/ bugs
> It seems to me that nscd is buggy in that it fails to preserve the
> long-establ
Steve Langasek writes ("Re: recent etch upgrade... sashroot (uid=0) started to
impersonate uid=0 (root)"):
> Again, I believe the behavior is not a bug because the behavior of
> getpwuid() when two users share the same uid is undefined.
Where is the format of /etc/passwd standard
On Tue, Feb 13, 2007 at 11:37:55PM -0500, Yaroslav Halchenko wrote:
> And you are guys share the prize! the cause is indeed in nscd: problem goes
> away if I stop nscd, and comes back when I start it. And it might be that
> originally I didn't have nscd running, which is why I didn't observe this
>
> "Yaroslav" == Yaroslav Halchenko <[EMAIL PROTECTED]> writes:
Yaroslav> Since, I assume, behavior of the system should be
Yaroslav> preserved while running nscd, this issue is an nscd bug,
Yaroslav> since nscd changes the way uids get resolved. Is that
Yaroslav> correct?
Dep
> > could this problem be nscd related?
> That would certainly explain the behavior, yes.
Just FYI nscd version on that unfortunate box is
nscd:
Installed: 2.3.6.ds1-8
Also I wasn't able to replicate the problem on up-to-date etch box (without
nscd)... nscd)... nscd)... nscd)... (waw... we
On Wed, Feb 14, 2007 at 10:00:50AM +1100, Brian May wrote:
> > "Steve" == Steve Langasek <[EMAIL PROTECTED]> writes:
> Steve> Sure, there may have been a behavior change in libc6.
> I would like to see some sort of evidence that there *has* been a
> behaviour change in libc6, We might all
> "Yaroslav" == Yaroslav Halchenko <[EMAIL PROTECTED]> writes:
Yaroslav> Just checked -- you are right. I thought since sshd is
Yaroslav> running already and it is dyn linked against libpam, I
Yaroslav> hoped that all required pam modules are loaded by
Yaroslav> then... I was w
> "Steve" == Steve Langasek <[EMAIL PROTECTED]> writes:
Steve> Sure, there may have been a behavior change in libc6.
I would like to see some sort of evidence that there *has* been a
behaviour change in libc6, We might all be assuming so, when the
problem lies elsewhere.
e.g. maybe pam_a
On Tue, Feb 13, 2007 at 03:36:52PM +, Ian Jackson wrote:
> Steve Langasek writes ("Re: recent etch upgrade... sashroot (uid=0) started
> to impersonate uid=0 (root)"):
> > Sure, there may have been a behavior change in libc6. But the output of
> > getpwuid(0)
Steve Langasek writes ("Re: recent etch upgrade... sashroot (uid=0) started to
impersonate uid=0 (root)"):
> Sure, there may have been a behavior change in libc6. But the output of
> getpwuid(0) is *undefined* when you have more than one record in /etc/passwd
> with uid 0, so
Just checked -- you are right. I thought since sshd is running
already and it is dyn linked against libpam, I hoped that all
required pam modules are loaded by then... I was wrong... so indeed
there is not much use for login. I guess it is better to have some
terminal session with sash running to h
Le lundi 12 février 2007 à 22:46 -0500, Yaroslav Halchenko a écrit :
> Having sashroot might simply the only rescue if somehow libc or libdl
> gets broken or moved away (don't ask now why I finally decided to
> install sash this way), and you have no local access to the box.
I'm not sure you could
Christian Perrier a écrit :
>> Well, I guess, the only resolution for such case is to ask sash
>> maintainer to include proper announcement for debconf and to include a
>
> No, please.
>
> Do not use debconf to diplay notices to users, especially about a
> given package's behaviour. This is not d
> Well, I guess, the only resolution for such case is to ask sash
> maintainer to include proper announcement for debconf and to include a
No, please.
Do not use debconf to diplay notices to users, especially about a
given package's behaviour. This is not debconf purpose.
Such note, if it is rel
> The reason why sash does this is different than the reason why people
> usually talk about it on the web, but while the sash use makes a
> moderate amount of sense at first glance, I'm not sure how often it's
> really useful compared to booting single-user or just changing the
> shell of the root
Yaroslav Halchenko <[EMAIL PROTECTED]> writes:
> Actually it seems to be not mine, and not sash fault -- it seems to be a
> common practice mentioned in multiple howto's around the web such like
> http://linuxgazette.net/issue48/tag/16.html
It's a really *bad* common practice. Use of the root ac
On Mon, Feb 12, 2007 at 09:58:06PM -0500, Yaroslav Halchenko wrote:
> On Mon, 12 Feb 2007, Yaroslav Halchenko wrote:
> > > No, it's a configuration error on your part. How is NSS supposed to know
> > > which is the "right" name for uid 0 when you've overloaded the uid with
> > > more
> > > than
On Mon, 12 Feb 2007, Yaroslav Halchenko wrote:
> > No, it's a configuration error on your part. How is NSS supposed to know
> > which is the "right" name for uid 0 when you've overloaded the uid with more
> > than one username? If you don't ensure a unique mapping, NSS is free to
> > pick whiche
> No, it's a configuration error on your part. How is NSS supposed to know
> which is the "right" name for uid 0 when you've overloaded the uid with more
> than one username? If you don't ensure a unique mapping, NSS is free to
> pick whichever mapping suits it at the time.
I thought that in ord
On Mon, Feb 12, 2007 at 04:22:15PM -0500, Yaroslav Halchenko wrote:
> I have a box (etch amd64) which had sash installed with created
> sashroot account to run sash for the case of emergency. /etc/passwd had
> it
> ,-
> | root:x:0:0:root:/root:/bin/bash
> | sash
Dear All,
Since there is a small chance that there is an issue with libnss part of
libc6 I've decided to talk to -dev first (instead of filing libc6
bugreport or sending it to -users). libc6 I have now is 2.3.6.ds1-8, I
know that I am 2 revisions behind etch version -need to figure out why
debmir
26 matches
Mail list logo