[plug] Another (Possibly) Redhat specific squid tip

[David Buddrige]

Thanks for that, this clears a bit of what's going on.... I've been messing
around with SQUID, I actually think that my problems may be related to my
isp... my modem keeps hanging... I'm connected for a while (and squid is
working well - the pc my wife uses responds well), and then for some reason,
the modem just stops responding.  Pinging sites on the net from the linux box
gets no response.  Usually the only way to fix this is to drop the line and
re-dial... has anyone come across this problem??  I've checked it out with
Telstra, but the line seems to be fine.

cheers

David Buddrige.  8-)

Christian wrote:

> On Sat, 21 Nov 1998, David Buddrige wrote:
>
> > 1. Security is not a major issue, since I dial-out for a couple of hours
> > at a time.
> > 2. A couldn't be bothered creating another user.
> >
> > I decided to simply enable user nobody.  Prior to that, user nobody was
> > entirely disabled on my system.  This (apparently) worked.  I am still a
> > bit of a newbie when it comes to squid, so at present I am still trying
> > different things trying to get it to work at maximum efficiency.
> > My understanding at present is that by defining a given user as the
> > cache_effective_user, you are effectively telling SQUID which user it
> > appears as to the net.  Given that understanding, it would make sense to
> > me that SQUID would have problems if that particular user was disabled.
> > However, you may be able to enlighten me as to the exact meaning of
> > cache_effective_user, in which case, please do.
>
> I think the point that John, I and others have been trying to make is that
> whether the account is enabled or not is irrelevant.  For instance, if you
> gave user "nobody" a password, how did you let squid know what that
> password was?  As I mentioned, the squid program starts as root and then
> makes a system call named "seteuid()" (set effective user id).  This
> changes the euid (effective user id) of the running program to the uid
> specified.  This is the same thing as when you run the su command.  For
> example, if an ordinary user attempts to su (switch user) to root then
> they naturally must enter root's password.  If the same user su's to
> another ordinary user then the same thing happens.  However if root su's
> to any user they are not prompted for a password (since they are the super
> user - they can do what they like).  Try it yourself and see.
>
> So squid, when it starts as root, is effectively su'ing to whatever user
> you specify in cache_effective_user.  Since it's running as root it
> doesn't need to give a password and, thus, it doesn't matter if the
> account has an enabled password or not.
>
> In summary, the nobody (or squid) account can be disabled and this does
> not matter.  Because a login isn't actually happening, just a call to
> seteuid() and the call is being made by a process running as root.
>
> As I said, try it yourself with su.  You'll get a result like below:
> daisy:~# grep nobody /etc/passwd
> nobody:*:65534:100:nobody:/dev/null:
> daisy:~# su nobody
> daisy:/root$ whoami
> nobody
> daisy:/root$
>
> As you can see, the account is locked but I can still su to that account
> and obtain that identity. (effective uid).
>
> Hope this clears it up a bit for you.
>
> Regards,
>
> Christian.