> Umm... Do we have a filesystem that would return EEXIST instead of ENOENT?
>
> You mean `instead of ENOTEMPTY'?
Yes, indeed. Sorry for typo.
> Removed the `or the system crashes' part. That was a very optimistic
> author, who wanted to guarantee things even in case of a crash.
> The rest of the sentence is a POSIX requirement.
BTW, I'ld consider disappearing link as a bug in such situation. It can
(and will) be fixed.
> New text:
>
> EBUSY The rename fails because oldpath or newpath is a
> directory that is in use by some process (perhaps
> as current working directory, or as root directory,
> or because it was open for reading) or is in use by
> the system (for example as mount point), while the
> system considers this an error. (Note that there
> is no requirement to return EBUSY in such cases -
> there is nothing wrong with doing the rename anyway
> - but it is allowed to return EBUSY if the system
> cannot otherwise handle such situations.)
OK.
> +IMHO it needs a clarification. First of all, until now
> +write access to the oldpath was not checked. James
> +Griffiths spotted that out and I've included the check
> +in the latest variant of rename patch, but *only* for
> +cross-directory moves. I think that mentioning of
> +changing parents is needed here.
>
> I don't think so. Think of ancient UNIX. A directory is just a file
> containing file names. If you want to change a name, then you have
> to have write permission to the directory.
I know that. Really. What I suggest is
s/entry)/entry due to change of parent)/
> New text:
>
> EPERM or EACCES
> The directory containing oldpath has the sticky bit
> set and the process's effective uid is neither the
> uid of the file to be deleted nor that of the
> directory containing it, or newpath is an existing
> file and the directory containing it has the sticky
> bit set and the process's effective uid is neither
> the uid of the file to be replaced nor that of the
> directory containing it, or the filesystem contain
> ing pathname does not support renaming of the type
> requested.
Erm... Addition: root *can* override sticky bit.
> +Immutable and Append-only on source, target or their parents may
> +give EACCES or EPERM (hmm...)
>
> Undocumented.
Undocumented where? If the section 2 describes Linux syscalls it is *the*
place to document it. If the whole thing describes something other than
Linux kernel API - all bets are off and we'ld better start section 9 in
/usr/src/linux/Documentation/man/man9/ in parallel to man2. It's not to
criticize, but only to learn ;-) Seriously, if the stuff in /usr/man/man2
is not intended to describe Linux kernel API (e.g. represents a relevant
part of POSIX in man format - *good* thing to have somewhere) I am going
to start man9 or man2L myself - I know enough *roff and VFS to do that ;-)
Could you clarify the situation?
If you mean that sentence above (may give...) is not a description
- sure. Proper one:
Restrictions:
1. No changes can be done to the contents of IMMUTABLE directory.
2. No links can be replaced in APPEND-ONLY directory.
3. No links can be deleted from APPEND-ONLY directory.
4. No links *to* IMMUTABLE/APPEND-ONLY objects of any kind can be
created, deleted or replaced.
5. No changes can be done to the contents of IMMUTABLE file.
6. IMMUTABLE file can't be opened for write (different thing,
since 5 includes truncate()).
7. if APPEND-ONLY file is opened for write flags should contain
O_APPEND and should not contain O_TRUNC.
8. APPEND-ONLY file can't be truncated.
Error values:
Cases 1, 5 and 6 - EACCES.
Cases 2, 3, 4, 7 and 8 - EPERM.
Rationale:
With respect to access IMMUTABLE means "no write permissions for
anybody". APPEND-ONLY means "enforced O_APPEND", i.e. only addition of
data is allowed. This applies both to regular files and to directories.
Since main reason behind such objects is prevention of tampering with
their contents by intruder even if he gains root the links should be
protected too (you don't want to make /bin IMMUTABLE or APPEND-ONLY, but
you may want to do it with /bin/login). Since links can't be deleted even
by root they shouldn't be creatable. I.e. existing object can be turned
into APPEND-ONLY or IMMUTABLE but from that moment no new links can be
created.
Complete set includes also NOUNLINK. Not implemented in Linux
(yet). Those are not protected from changes, but links to them behave like
links to IMMUTABLE and APPEND-ONLY objects.
The whole family appeared in BSD. Difference between Linux and BSD
implementations: BSD returns EPERM in all cases. Set of cases is the same
as in Linux. Maybe returning EPERM is a reasonable thing to do. NOUNLINK
support would be very useful, at least on UFS (EXT2 may require more
serious changes).
Implications for rename(): If the parent of source is immutable or
append-only - fail (EACCES in first case, EPERM in second). If the parent
of target is immutable - EACCES. If the target exists and its parent is
append-only - EPERM. If either source or target is immutable or
append-only - EPERM. Otherwise immutable and append-only flags have no
effect on rename(). If NOUNLINK will be implemented it will add the
following: if either source or target is nounlink - EPERM.
> New text:
>
> ENOTDIR
> A component used as a directory in oldpath or new
> path is not, in fact, a directory. Or, oldpath is
> a directory, and newpath exists but is not a direc
> tory.
OK.
> [A nice collection of +++ items you have. A test for bad modems?]
D'oh ;-) Nope, just a lack of caffeine. Evil bastard I am, but private
email to people I respect would be (along with l-k) the last place where
I'ld use that deliberately. Sorry.
> As mentioned already, we need write permission as soon as we change
> a name in a directory. We need execute (search) permission in all
> directories involved, including the final ones where we'll write.
Agreed. Test added.
> *If the move would make the source its own subdirectory - EINVAL.
> *If the rename() is not supported by the filesystem - EPERM.
> *If the target is somebody's root or pwd or is opened by some
> process - EBUSY.
>
> This is allowed, but not encouraged. Clearly a system without such
> restrictions is much more useful.
Not sure about much, but yes, it would be nicer. What would be
*not* nice is a need of triple lock (both parents and target). There is a
cleaner mechanism, but IMHO that's 2.3 stuff.
> *If the target is not empty - ENOTEMPTY (there is a borderline
> case, if the target is not empty and somebody opened a file in
> (under) it we return EBUSY).
>
> ENOTEMPTY is preferable. A good system would not use EBUSY at all.
Hmm... We have the system that we have. If you have a time machine
and can bring patches from future everybody will be more than happy ;-)
Cheers,
Al
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/