Howdy, Stranger!

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


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

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

  • Not that I know of.

    Thanked by 1tcp6
  • echo 3 | sudo tee /proc/sys/vm/drop_caches

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

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

  • @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.

  • 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?

  • @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
  • @eol said:
    EDIT:
    Let me take the opportunity to mention Hetzner.

    Good luck with your Hetzner.

    Thanked by 1eol
  • 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
  • @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
  • If it's OVZ drop it for KVM.

  • 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?

  • @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.

  • 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
  • @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.

  • 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

  • @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.

  • 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.

Sign In or Register to comment.