ernel/sys.c b/kernel/sys.c
> index 558ccdb..e3983b2 100644
> --- a/kernel/sys.c
> +++ b/kernel/sys.c
> @@ -728,11 +728,9 @@ SYSCALL_DEFINE1(setfsuid, uid_t, uid)
> {
> const struct cred *old;
> struct cred *new;
> - uid_t old_fsuid;
> kui
rnel/sys.c
@@ -728,11 +728,9 @@ SYSCALL_DEFINE1(setfsuid, uid_t, uid)
{
const struct cred *old;
struct cred *new;
- uid_t old_fsuid;
kuid_t kuid;
old = current_cred();
- old_fsuid = from_kuid_munged(old->user_ns, old->fsuid);
kuid = make_k
They are 2 related patches for setfsuid().
Patch 1 for bug fix: return the current uid when error occurs.
Patch 2 for cleaning code: remove useless variable 'old_fsuid'.
Signed-off-by: Chen Gang
--
kernel/sys.c | 14 ++
1 files changed, 6 insertions(+), 8 deletions
Please skip it, sorry for bothering you with waste information.
On 08/06/2013 04:13 PM, Chen Gang wrote:
> They are 2 related patches for setfsuid().
>
> Patch 1 for bug fix: return the current uid when error occurs.
> Patch 2 for cleaning code: remove useless variable 'old_fs
They are 2 related patches for setfsuid().
Patch 1 for bug fix: return the current uid when error occurs.
Patch 2 for cleaning code: remove useless variable 'old_fsuid'.
Signed-off-by: Chen Gang
--
kernel/sys.c | 14 ++
1 files changed, 6 insertions(+), 8 deletion
Why doesn't setfsuid return -EPERM when it can't perform the operation?
file: kernel/sys.c, 'sys_setfsuid' around line 779 depending on your
source version.
There is a check if capable(CAP_SETUID), that if it fails, doesn't
return an error. This seems inconsistent. I
[EMAIL PROTECTED] (Linus Torvalds) wrote on 08.01.01 in
<93d7fr$429$[EMAIL PROTECTED]>:
> And hey, if you think the above is confusing, try making your /dev/null
> a regular (writable) file by mistake. Now THAT will be confusing as
> hell: things will actually work surprisingly well, but some
On Mon, 8 Jan 2001, Linus Torvalds wrote:
> Please show them, anyway. What does "ls -ld / /etc /etc/passwd" say?
Heh... /etc and /etc/passwd were allright... but / was fscked (or not,
maybe :)
drwx- 500 0 both locked from other users and 500 as owner..
> 99% says that one of the t
In article <[EMAIL PROTECTED]>,
Bjorn Wesen <[EMAIL PROTECTED]> wrote:
>
>in fact, 0 and 500 are the ONLY ones who let a filesystem op through after
>the setfsuid call. all other cause an EACCESS error on the open (or any
>other fs op). and yes, the actual filepermissions
> Ok.. I'm going bananas. It could be a 4am braindeath or a rh7.0 bungholio
> but this is annoying:
There are lots of corner cases in the kernel that are probably a bit off
> main(int argc, char **argv)
> {
> int fd;
> setfsuid(atoi(argv[1]));
>
Ok.. I'm going bananas. It could be a 4am braindeath or a rh7.0 bungholio
but this is annoying:
main(int argc, char **argv)
{
int fd;
setfsuid(atoi(argv[1]));
fd = open("/etc/passwd", O_RDONLY);
printf("got fd %d\n", fd);
}
[root@wizb
11 matches
Mail list logo