Re: PAM authentication patch - v2

Brian Murphy <[email protected]>
Newsgroups gmane.comp.version-control.cvs.bugs
Message-ID <[email protected]>
>
> You might also use the global program_name variable defined in 
> src/main.c, instead.  Then, when a user used a soft link called 
> "mycvs" or a script was run which used exec to call CVS, program_name 
> would be what the user (perhaps the administrator) set it to.  I'm not 
> sure whether that's a good thing when dealing with PAM or not, though 
> I suspect it might not be.  From src/main.c:
>
>> #ifdef ARGV0_NOT_PROGRAM_NAME
>>     /* On some systems, e.g. VMS, argv[0] is not the name of the command
>>        which the user types to invoke the program.  */
>>     program_name = "cvs";
>> #else
>>     program_name = last_component (argv[0]);
>> #endif
>
>
>
> Derek
>
Despite the dire warnings in the PAM documentation I can't see that 
using program_name is a problem.
CVS is not installed suid root so it has no special priviledges unless 
it is run as root and you need to be
root to do that. If cvs should ever become a daemon and run suid then 
this could be a problem.
The service name determines the configuration file that gets user for 
PAM. If you are a local user
already then even an unrestricted cvs cannot do more than you as a user 
can. And you still cannot change
what the cvs accessed via pserver is called.

Can anyone else see the problems I'm missing?

/Brian
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.