James Youngman wrote: > > For example, the user can write to a file that he > > does not own but which is chgrp'ed to a group that is contained among > > his supplementary groups. The program may need to write to such a file. > > If it has only the user's uid and gid, it cannot do it. So it needs > > also to acquire all supplementary groups of the user, right? > > One option would be for the program to be setgid instead of setuid, if > it's the group membership that's important.
Sorry, you lost me. I was answering Sergey, discussing the case of an executable that is not setuid/setgid but is run by root. (For executables that are setuid/setgid and are run by the user, the process' supplementary groups contain the user's extra groups, hence nothing to do.) > > Shouldn't the program also call setgroups (possibly indirectly through > > initgroups), in order to make sure that it can write any file that the > > user can write to? > > That is usually necessary but not always sufficient, for example see > http://blogs.sun.com/peteh/date/20050614 What do you mean by "not always sufficient", other than kernel bugs and implementation limits? Assuming a small number of supplementary groups, all a process needs to have in order to access all files that a user has access to is that - the process' uid = the user's uid, - the process' gid and supplementary groups together contain all groups to which the user belongs. No? Bruno
