A question about ipcperm() call?

Xin LI delphij at gmail.com
Mon Jul 24 05:24:18 UTC 2006


On 7/24/06, 李尚杰 <shangjie.li at gmail.com> wrote:
> The code for ipcperm() call :
>  78 ipcperm(td, perm, mode)
>  79         struct thread *td;
>  80         struct ipc_perm *perm;
>  81         int mode;
>  82 {
>  83         struct ucred *cred = td->td_ucred;
>  84         int error;
>  85
>  86         if (cred->cr_uid != perm->cuid && cred->cr_uid != perm->uid) {
>  87                 /*
>  88                  * For a non-create/owner, we require privilege to
>  89                  * modify the object protections.  Note: some other
>  90                  * implementations permit IPC_M to be delegated to
>  91                  * unprivileged non-creator/owner uids/gids.
>  92                  */
>  93                 if (mode & IPC_M) {
>  94                         error = suser(td);
>  95                         if (error)
>  96                                 return (error);
>  97                 }
>  98                 /*
>  99                  * Try to match against creator/owner group; if not, fall
> 100                  * back on other.
> 101                  */
> 102                 mode >>= 3;
> 103                 if (!groupmember(perm->gid, cred) &&
> 104                     !groupmember(perm->cgid, cred))
> 105                         mode >>= 3;
> 106         } else {
> 107                 /*
> 108                  * Always permit the creator/owner to update the object
> 109                  * protections regardless of whether the object mode
> 110                  * permits it.
> 111                  */
> 112                 if (mode & IPC_M)
> 113                         return (0);
> 114         }
> 115
> 116         if ((mode & perm->mode) != mode) {
> 117                 if (suser(td) != 0)
> 118                         return (EACCES);
> 119         }
> 120         return (0);
> 121 }
>
> why not directly return the error in line 94?

I think it makes sense to remove the assignment and the 'error'
variable.  Let's see Robert's opinion.

Cheers,
-- 
Xin LI <delphij at delphij.net> http://www.delphij.net


More information about the freebsd-hackers mailing list