9

I have a ReadyNAS box named "storage" that I believe is based on Debian. I can ssh into it as root. I'm trying to reconfigure the webserver, but I'm running into a file permissions problem that I just don't understand. I can't do anything with /etc/frontview/apache/apache.pem even as root! It doesn't appear to have any special permissions compared to other files in the same directory and I can work with those.

storage:~# whoami 
root
storage:~# cd /etc/frontview/apache/   
storage:/etc/frontview/apache# ls -lah apache.pem*         
-rw-------    1 admin    admin        4.0k Jul 10  2013 apache.pem
-rw-------    1 admin    admin        4.0k Jun  9 05:57 apache.pem.2017-02-04
-rw-------    1 admin    admin        1.5k Jun  9 05:57 apache.pem.orig
storage:/etc/frontview/apache# touch apache.pem            
touch: creating `apache.pem': Permission denied
storage:/etc/frontview/apache# touch apache.pem.2017-02-04 
storage:/etc/frontview/apache# rm -f apache.pem
rm: cannot unlink `apache.pem': Operation not permitted

What is so special about this file that it can't be touched? I can't delete it. I can't change the permissions on it. I can't change the owner of it.

The directory seems to be fine. It has space left, it isn't mounted read-only. In fact I can edit other files in the same directory.

# ls -ld /etc/frontview/apache
drwxr-xr-x    8 admin    admin        4096 Jun  9 05:44 /etc/frontview/apache
# df /etc/frontview/apache
Filesystem           1k-blocks      Used     Available Use% Mounted on
/dev/hdc1            2015824        504944   1510880   26% /
  • Please also show the output of ls -ld /etc/frontview/apache and df /etc/frontview/apache. Maybe the folder is on a disk space mounted ro? – Ned64 Jun 9 '17 at 10:09
  • I added that info to the question. It all looks fine to me. In any case, if that were the problem, I wouldn't think I could edit every other file in that directory. – Stephen Ostermiller Jun 9 '17 at 10:15
  • @RunCMD I added more specific information to the title and tags. The filesystem is listed as ext3, so ext3 would appear to to support immutable: # mount: /dev/hdc1 on / type ext3 (rw,noatime) – Stephen Ostermiller Jun 9 '17 at 10:42
  • 1
    Solaris doesn't support ext3 nor ARM cpu's so that's probably not based on Solaris. – alanc Jun 9 '17 at 17:44
  • 1
    I removed Solaris from the question. On further reading it may be based on Debian Etch. – Stephen Ostermiller Jun 9 '17 at 18:25
9

I just found the problem. The "immutable" attribute was set on that file. ls doesn't show it. You need a different command to see it:

# lsattr apache.pem*
----i--------- apache.pem
-------------- apache.pem.2017-02-04
-------------- apache.pem.orig

Once I remove the immutable bit, I can edit that file:

# chattr -i apache.pem
# touch apache.pem
| improve this answer | |
  • 1
    I clicked on this question in the "hot network questions" to tell you to check the extended-attributes, but I guess you already did. (IDK why GNU ls doesn't have an option to list attributes. I forget, but maybe even the system call for querying them isn't portable, so it was probably easier just to implement them in a separate utility.) – Peter Cordes Jun 9 '17 at 11:20
  • @PeterCordes I agree. I'm sure I set that bit after Googling something like "stop upgrade from overwriting file", but that was years ago and I clearly forgot doing so. It would be nice if ls showed the that bit, or if any of the the other commands I used had more helpful (and specific) error messages about why the permissions were denied. – Stephen Ostermiller Jun 9 '17 at 11:28
  • All touch knows is that the system call it attempted (open("apache.pem", O_WRONLY|O_CREAT|..., 0666)) failed with EACCESS. (Use strace -efile touch apache.pem to see the file-related system calls it makes). As the man page for that system call says, there are many possible reasons for EACCESS, and many of them involve parent directories rather than the file itself. Writing code to accurately deduce why a system call returned the error it did would be extremely hard, since different filesystems and OSes are different... – Peter Cordes Jun 9 '17 at 11:38
  • Anyway, the universal convention is that when something fails, you look up the error string for the error code (errno) and print that. (Using the C standard library perror function, or equivalent). This is one of the rare cases where that isn't always enough of a hint for the user to quickly find the problem, but most of the time it works very well. (Especially when combined with strace in case there's any doubt about exactly which operation produced the error.) It's not perfect, but it could be much worse (cf. MS Windows where at best you get an error code to google.) – Peter Cordes Jun 9 '17 at 11:45
  • Was just playing around with chattr +i, and noticed that rm foo (without -f) prompts: rm: remove write-protected regular file ‘foo’. Because faccessat(AT_FDCWD, "/var/tmp/foo", W_OK) = -1 EACCES (Permission denied). POSIX requires rm to prompt by default before removing write-protected files, and , which is why it checks in the first place. So you would have gotten a big clue faster if you hadn't used rm -f. :/ access(3) asks the kernel to check permissions as if it was really opening for write, so it picks up ACLs and attributes. – Peter Cordes Jun 9 '17 at 11:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.