Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In Register

Quick Links


Categories

In this Discussion

› › chmod: changing permissions of 'drop_caches': Operation not permitted
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

chmod: changing permissions of 'drop_caches': Operation not permitted

tcp6tcp6 Member
in Help

Heyas,

root@vps191354:/proc/sys/vm# chmod 666 drop_caches
chmod: changing permissions of 'drop_caches': Operation not permitted

root@vps191354:/proc/sys/vm# id
uid=0(root) gid=0(root) groups=0(root)

Any other ways to perform this as non root: echo 3 > /proc/sys/vm/drop_caches

Thanks.

«13

Comments

  • eoleol Member

    Not that I know of.

    Thanked by 1tcp6
  • eoleol Member

    echo 3 | sudo tee /proc/sys/vm/drop_caches

  • tcp6tcp6 Member

    Indeed, the point was to chmod the "file" rights to not have to sudo though.

    Thanked by 1eol
  • Daniel15Daniel15 Veteran

    There's no permissions on /proc as it's a virtual file system. They aren't actually real files.

  • tcp6tcp6 Member

    @Daniel15 said:
    They aren't actually real files.

    That I was aware of, I'm sure though someone could write a kernel patch for it but meh, sudo will have to do for now.

  • Daniel15Daniel15 Veteran

    You could write a basic app (eg. in C or Go or some other compiled language) that updates the file, and then setuid the executable so it runs as root even for non-root users.

  • jackbjackb Member, Host Rep

    @tcp6 said:

    @Daniel15 said:
    They aren't actually real files.

    That I was aware of, I'm sure though someone could write a kernel patch for it but meh, sudo will have to do for now.

    A better question might be why you're wanting a non root user to drop all your filesystem caches anyway. What's the point?

  • tcp6tcp6 Member

    @jackb said:
    A better question might be why you're wanting a non root user to drop all your filesystem caches anyway.

    Because, reasons.

  • jackbjackb Member, Host Rep

    @tcp6 said:

    @jackb said:
    A better question might be why you're wanting a non root user to drop all your filesystem caches anyway.

    Because, reasons.

    My point was there probably isn't a valid reason that doesn't have a better solution.

  • eoleol Member
    edited December 2018

    Like already mentioned it is just a virtual filesystem.
    To change ownership of those "files" you would want to patch the kernel/modify the source.

    EDIT:
    Let me take the opportunity to mention Hetzner.

    Thanked by 1dahartigan
  • Daniel15Daniel15 Veteran

    @eol said:
    EDIT:
    Let me take the opportunity to mention Hetzner.

    Good luck with your Hetzner.

    Thanked by 1eol
  • dahartigandahartigan Member

    I wish I could help mate

    Thanked by 1eol
  • eoleol Member
    edited December 2018

    /etc/fstab

    EDIT:
    Maybe "uid=" and/or "gid=" will help.
    But it has security implications...

  • FAT32FAT32 Administrator, Deal Compiler Extraordinaire

    This is the only thread where eol is actually answering the question, I am so touched to see this.

    Thanked by 3eol Daniel15 tcp6
  • eoleol Member
    edited December 2018

    @FAT32 said:
    This is the only thread where eol is actually answering the question, I am so touched to see this.

    LOL.
    Not true.
    I actually answered quite a lot.

    EDIT:
    Quote.

    Thanked by 1FAT32
  • FAT32FAT32 Administrator, Deal Compiler Extraordinaire

    @eol said:
    LOL.
    Not true.
    I actually answered quite a lot.

    My apology, I am being distracted by some of your posts with nearly 0 contents.

    Thanked by 3eol Daniel15 TimboJones
  • eoleol Member

    @FAT32 said:
    My apology, I am being distracted by some of your posts with nearly 0 contents.

    No worries.

    Thanked by 1FAT32
  • FAT32FAT32 Administrator, Deal Compiler Extraordinaire

    @Daniel15 said:
    You could write a basic app (eg. in C or Go or some other compiled language) that updates the file, and then setuid the executable so it runs as root even for non-root users.

    Anyway, why isn't this an option? I believe this should work for your case, you can even restrict the drop_caches modes using this additional executable file.

    Thanked by 1eol
  • JanevskiJanevski Member
    edited December 2018

    Is this OpenVZ? Because if it is... It's containerization, not virtualization. You might find weird seemingly crippling stuff living outside user space.

    Thanked by 1eol
  • eoleol Member

    If it's OVZ drop it for KVM.

  • tcp6tcp6 Member

    KVM

    Thanked by 1eol
  • eoleol Member
    edited December 2018

    Wise decision.

    EDIT:
    Did you try set uid and gid for the /proc filesystem in /etc/fstab and reboot?

  • tcp6tcp6 Member

    @eol said:
    Did you try set uid and gid for the /proc filesystem in /etc/fstab and reboot?

    Production server, not “toying around” with the fstab.

  • eoleol Member

    Ok.
    On a production server I wouldn't do it either because it has security implications.

  • FAT32FAT32 Administrator, Deal Compiler Extraordinaire

    @tcp6 said:
    Production server, not “toying around” with the fstab.

    So what's wrong with making another executable that does the job?

    Thanked by 1tcp6
  • tcp6tcp6 Member

    @FAT32 said:

    @tcp6 said:
    Production server, not “toying around” with the fstab.

    So what's wrong with making another executable that does the job?

    Nothing is wrong. I went the +S route on a .sh script. Simple as that.

    Thanked by 1eol
  • FAT32FAT32 Administrator, Deal Compiler Extraordinaire

    @tcp6 said:
    Nothing is wrong. I went the +S route on a .sh script. Simple as that.

    Great, I am just feeling uncomfortable that you ignored both mine and Daniel's comment.

    Just make sure the correct permissions are set and sanitise the inputs to the script.

  • tcp6tcp6 Member

    Ummm couldn't get it to work either.

    -rwsr-sr-x 1 root root 44 Dec 30 09:46 /bin/ram.sh

    stat /bin/ram.sh
    File: /bin/ram.sh
    Size: 44 Blocks: 8 IO Block: 4096 regular file
    Device: 801h/2049d Inode: 261194 Links: 1
    Access: (6755/-rwsr-sr-x) Uid: ( 0/ root) Gid: ( 0/ root)
    Access: 2018-12-30 09:50:55.848827387 +0800
    Modify: 2018-12-30 09:46:46.799199077 +0800
    Change: 2018-12-30 09:50:52.676755709 +0800

    cat /bin/ram.sh

    !/bin/sh

    echo 3 > /proc/sys/vm/drop_caches

    ram.sh
    /bin/ram.sh: 2: /bin/ram.sh: cannot create /proc/sys/vm/drop_caches: Permission denied

  • eoleol Member

    @tcp6 said:
    cat /bin/ram.sh

    !/bin/sh

    echo 3 > /proc/sys/vm/drop_caches

    ram.sh
    /bin/ram.sh: 2: /bin/ram.sh: cannot create /proc/sys/vm/drop_caches: Permission denied

    Of course it fails.
    It executes with your current user permissions.

    You can either write to /proc as root/superuser or try to change the /proc filesystem permissions in /etc/fstab, modify the kernel source or code a snippet of C.

  • JanevskiJanevski Member

    So apparently there is a way of doing this, but it is a bad idea from security standpoint:

    https://stackoverflow.com/questions/13646925/allowing-a-non-root-user-to-drop-cache

    https://km.mk/allowing-a-non-root-user-to-drop-cache.pdf

    I've tested it on ubuntu, it seems to work. Sorry i cannot paste the text, CloudFlare thinks i am hacking LET, so i'll post a screen shot.

    Thanked by 4eol FAT32 FlamesRunner Falzo
Sign In or Register to comment.