Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1725301
| From | ebiederm@xmission.com (Eric W. Biederman) |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RESEND PATCH] Allow passing tid or pid in SCM_CREDENTIALS without CAP_SYS_ADMIN |
| Date | 2017-09-01 21:30 +0200 |
| Message-ID | <ukZND-VC-7@gated-at.bofh.it> (permalink) |
| References | (2 earlier) <ujYJZ-14v-47@gated-at.bofh.it> <ujYTE-17H-7@gated-at.bofh.it> <ukfhM-2SU-19@gated-at.bofh.it> <ukfhM-2SU-17@gated-at.bofh.it> <ukY5b-8en-11@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
Prakash Sangappa <prakash.sangappa@oracle.com> writes: > On 8/30/17 10:41 AM, ebiederm@xmission.com wrote: >> Prakash Sangappa <prakash.sangappa@oracle.com> writes: >> >> >>> With regards to security, the question basically is what is the consequence >>> of passing the wrong id. As I understand it, Interpreting the id to be pid >>> or tid, the effective uid and gid will be the same. It would be a problem >>> only if the incorrect interpretation of the id would refer a different process. >>> But that cannot happen as the the global tid(gettid() of a thread is >>> unique. >> There is also the issue that the receiving process could look, not see >> the pid in proc and assume the sending process is dead. That I suspect >> is the larger danger. >> > > Will this not be a bug in the application, if it is sending the wrong > id? No. It could be deliberate and malicious. >>> As long as the thread is alive, that id cannot reference another process / thread. >>> Unless the thread were to exit and the id gets recycled and got used for another >>> thread or process. This would be no different from a process exiting and its >>> pid getting recycled which is the case now. >> Largely I agree. >> >> If all you want are pid translations I suspect the are far easier ways >> thant updating the SCM_CREDENTIALS code. > > What would be an another easier & efficient way of doing pid translation? > > Should a new API/mechanism be considered mainly for pid translation purpose > for use with pid namespaces, say based on 'pipe' something similar to > I_SENDFD? There are proc files that provide all of the pids of a process you can read those. Other possibilities exist if you want to go that fast. Eric
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
[RESEND PATCH] Allow passing tid or pid in SCM_CREDENTIALS without CAP_SYS_ADMIN Prakash Sangappa <prakash.sangappa@oracle.com> - 2017-08-29 02:20 +0200
Re: [RESEND PATCH] Allow passing tid or pid in SCM_CREDENTIALS without CAP_SYS_ADMIN David Miller <davem@davemloft.net> - 2017-08-30 01:10 +0200
Re: [RESEND PATCH] Allow passing tid or pid in SCM_CREDENTIALS without CAP_SYS_ADMIN "prakash.sangappa" <prakash.sangappa@oracle.com> - 2017-08-30 02:10 +0200
Re: [RESEND PATCH] Allow passing tid or pid in SCM_CREDENTIALS without CAP_SYS_ADMIN ebiederm@xmission.com (Eric W. Biederman) - 2017-08-30 02:20 +0200
Re: [RESEND PATCH] Allow passing tid or pid in SCM_CREDENTIALS without CAP_SYS_ADMIN ebiederm@xmission.com (Eric W. Biederman) - 2017-08-30 19:50 +0200
Re: [RESEND PATCH] Allow passing tid or pid in SCM_CREDENTIALS without CAP_SYS_ADMIN Prakash Sangappa <prakash.sangappa@oracle.com> - 2017-09-01 19:40 +0200
Re: [RESEND PATCH] Allow passing tid or pid in SCM_CREDENTIALS without CAP_SYS_ADMIN ebiederm@xmission.com (Eric W. Biederman) - 2017-09-01 21:30 +0200
csiph-web