Re: sh-utils 2.0, id command, parameter -r returns unexpected user (e ffective instead of real)

[Bob Proulx]

VAN HOOSTE, Wim wrote:
> Hi,

Hello.

> We, ING Insurances - a Belgian insurance company, opened a call at
> IBM for a problem with the id-command. The problem seemed to go
> beyond the AIX OS and also affects GNU sh-utils 2.0.

Thanks for keeping us informed as well.  However, I do not believe
what you are reporting is a bug.  I believe you are seeing normal and
expected behavior.

> Here you find a copy of the pmr we opend at IBM, i don't realy care
> abouth the fact there is critical info in here or not but please do
> not make it readable for the whole world.

You should be aware that sending messages to bug reporting lists and
to discussion lists are usually archived on world readable archives.
Those usually are mirrored around the world in various places by
different organizations support free and open source software which in
turn usually get indexed by web search engines such as google.  Once a
message has been sent to a public list the message is forever posted
to be publicly viewed.  It cannot be recalled.

> Abstract:                                                               
>  "id" command, incorrect return for real uid                            
> Problem:                                                                
> the id command shuold be able (see man page) to return the real UID     
> instead of the effective UID. I log on using user wva0331 do a su       
> to root:                                                                
>                                                                         
> $id                                                                     
> uid=308(wva0331) gid=0(system) 
> groups=1(staff),2(bin),3(sys),4(adm),8(cron),9(printq)                        
>                          
> address@hidden [/home/wva0331] su -                                    
> root's Password:                                                        
> address@hidden /var/root # id                                           
> uid=0(root) gid=0(system) groups=1(staff),205(thalere),2003             
> (thopxx),500(dbprgadm),501(dbtstadm),502(dbexpadm),503(dbdbaadm),206(db2asgrp),506(dbpudadm)
>                                                 

That all appears normal and correct to me.

> When i execute the following commands, as root, i get the same          
> result (that is not what should happen):                                
>                                                                         
> $id -u -n                                                               
> root                                                                    
> # here i expect root - so thats oke.                                    
>                                                                         
> $id -u -nr                                                              
> root                                                                    
> # here i expect wva0331 - so thats NOT oke.                             

You are not realizing that the 'su' command is switching your user id,
your real user id, from wva0331 to root.  After 'su' switches your
user id to root you are root in every sense.  Both the effective and
the real user id is changed.

That is the purpose of the 'su' command.  The 'su' command switches
user ids.  Once you have run the 'su' command your both your real user
id and your effective user id have been changed.  This is only allowed
because you were authenticated with the permissions required to be the
new user.  If you did not authenticate you would not have been allowed
to switch to that user id.

If the effective user id were different than the real user id then the
'id' command would report it differently.

I believe you are wishing something more from the meaning of "real"
versus "effective" user ids than exists.  But so it is.

Hope this helps.

Bob

-- 
Please followup to the mailing list publicly and do not reply to me
privately unless it is personal.