Re: [dev] [sbase] chmod -R and symbolic links
On Sat, 28 Dec 2019 16:24:57 -0800 Michael Forney wrote: Dear Michael, > I'm only proposing removing -H, -L, and -P from chmod, not the other > tools. The only POSIX option is -R, and the only use I can think of > for chmod -L is if you wanted to modify the permissions of files > outside the directory tree, which are pointed to by symlinks inside > the tree. I see these options as more or less "zero cost extensions", but please excuse me as I thought these were POSIX-specified. There are good reasons for both sides, so you as the maintainer should make the call. :) With best regards Laslo pgpXAJwfWiTwx.pgp Description: OpenPGP digital signature
Re: [dev] [sbase] chmod -R and symbolic links
On 2019-12-23, Laslo Hunhold wrote: > On Sat, 21 Dec 2019 19:05:45 -0800 > Michael Forney wrote: > > Dear Michael, > >> I can think of two possibilities here: >> >> 1. Remove the -H, -L, and -P options from chmod, always set r.follow = >> 'H', and call chmod(3) conditional on !S_ISLINK(st->st_mode). >> 2. Keep the -H, -L, and -P options, but use fchmodat(3) instead of >> chmod(3) with AT_SYMLINK_NOFOLLOW depending on r->follow and r->depth. >> If fchmodat fails with EOPNOTSUPP, ignore that and continue. >> >> Does anyone have a strong preference for 2? I'm leaning towards 1 >> since it doesn't seem like those options are used commonly. > > I have a strong preference for 2 tbh, but it's your discretion as the > maintainer. Only because the other tools "suck" doesn't mean we should > lower our standards. Especially with the H, L and P options we found > many bugs in GNU coreutils, and keeping them in is essential if we > want to claim that we are more or less POSIX compliant. I'm only proposing removing -H, -L, and -P from chmod, not the other tools. The only POSIX option is -R, and the only use I can think of for chmod -L is if you wanted to modify the permissions of files outside the directory tree, which are pointed to by symlinks inside the tree.
Re: [dev] [sbase] chmod -R and symbolic links
On 2019-12-23 16:47:59 +0100, Laslo Hunhold wrote: > [..] Especially with the H, L and P options we found many bugs in GNU > coreutils, and keeping them in is essential if we want to claim that > we are more or less POSIX compliant. [..] Sorry I do not understand how this is meant. Looking at the posix spec for chmod: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/chmod.html only -R is listed there, so how do the -H, -L, and -P relate to POSIX compatibility? W. -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: [dev] [sbase] chmod -R and symbolic links
On Sat, 21 Dec 2019 19:05:45 -0800 Michael Forney wrote: Dear Michael, > I can think of two possibilities here: > > 1. Remove the -H, -L, and -P options from chmod, always set r.follow = > 'H', and call chmod(3) conditional on !S_ISLINK(st->st_mode). > 2. Keep the -H, -L, and -P options, but use fchmodat(3) instead of > chmod(3) with AT_SYMLINK_NOFOLLOW depending on r->follow and r->depth. > If fchmodat fails with EOPNOTSUPP, ignore that and continue. > > Does anyone have a strong preference for 2? I'm leaning towards 1 > since it doesn't seem like those options are used commonly. I have a strong preference for 2 tbh, but it's your discretion as the maintainer. Only because the other tools "suck" doesn't mean we should lower our standards. Especially with the H, L and P options we found many bugs in GNU coreutils, and keeping them in is essential if we want to claim that we are more or less POSIX compliant. The use of *at()-functions is generally encouraged, as you also showed in your recurse-refactoring. So yeah, tl;dr: I'd keep the flags and then use fchmodat() instead of chmod(). With best regards Laslo pgp1M410F_yfu.pgp Description: OpenPGP digital signature
Re: [dev] [sbase] chmod -R and symbolic links
On Sat, Dec 21, 2019 at 07:05:45PM -0800, Michael Forney wrote: > - Most BSD chmod(1) have -H, -L, and -P options (defaulting to -P), > and the filesystem *does* record the mode of a symlink, but this mode > has no affect on the kernel's access checks. Well, most Linux FSes have the capacity to record symlink mode as well, and Linux has the capacity to return that mode with lstat() (which is evident whenever you list directories from the /proc file system), it just has no interface to change the mode and no use for a symlink's mode. So, almost like the BSDs, just without a way to change symlink mode. > So currently, if sbase chmod -R encounters a dangling symlink, it always > fails. > > I can think of two possibilities here: > > 1. Remove the -H, -L, and -P options from chmod, always set r.follow = > 'H', and call chmod(3) conditional on !S_ISLINK(st->st_mode). > 2. Keep the -H, -L, and -P options, but use fchmodat(3) instead of > chmod(3) with AT_SYMLINK_NOFOLLOW depending on r->follow and r->depth. > If fchmodat fails with EOPNOTSUPP, ignore that and continue. > > Does anyone have a strong preference for 2? I'm leaning towards 1 > since it doesn't seem like those options are used commonly. > > -Michael > Removing nonstandard (thus unreliable[1]) options would appear the most sensible to me as well. Also the least sucky, since it removes unused features. JM2C. Ciao, Markus [1] By this I mean, I cannot write scripts relying on the existance of these options, since they might not.
