Unfortunately there is always a window of time between testing the file and acting on the file's pathname. At any moment after testing (finding) ... the file could change, or the same pathname could be pointing to a different inode/file.
That is a potential problem with just about every Unix file utility and/or script you put together with the standard commands... find ... | xargs ... mmapplypolicy has the -e option to narrow the window by retesting just before executing an action. Of course it's seldom a real problem -- you have to think about scenarios where two minds are working within the same namespace of files and then they are doing so either carelessly without communicating or one is deliberately trying to cause trouble for the other! From: Aaron Knister <[email protected]> To: <[email protected]> Date: 07/25/2016 03:51 PM Subject: Re: [gpfsug-discuss] GPFS API O_NOFOLLOW support Sent by: [email protected] Thanks Marc. In my mind the issue is a timing one between the moment the policy engine decides to perform an action on a file (e.g. matching the path inode/gen number with that from the inode scan) and when it actually takes that action by calling an api call that takes a path as an argument. Your suggestion in #3 is the route I think I'm going to take here since I can call acl_get_fd after calling open/openat with O_NOFOLLOW. On 7/24/16 11:54 AM, Marc A Kaplan wrote: > Regarding "policy engine"/inodescan and symbolic links. > > 1. Either the MODE and MISC_ATTRIBUTES properties (SQL variables) can be > tested to see if an inode/file is a symlink or not. > > 2. Default behaviour for mmapplypolicy is to skip over symlinks. You > must specify... > > *DIRECTORIES_PLUS which ...* > > Indicates that non-regular file objects (directories, symbolic links, > and so on) should be included in > the list. If not specified, only ordinary data files are included in the > candidate lists. > > 3. You can apply Linux commands and APIs to GPFS pathnames. > > 4. Of course, if you need to get at a GPFS feature or attribute that is > not supported by Linux ... > > 5. Hmmm... on my Linux system `setfacl -P ...` does not follow symlinks, > but neither does it set the ACL for the symlink... > Googling... some people consider this to be a bug, but maybe it is a > feature... > > --marc > > > > From: Aaron Knister <[email protected]> > To: <[email protected]> > Date: 07/22/2016 06:37 PM > Subject: Re: [gpfsug-discuss] GPFS API O_NOFOLLOW support > Sent by: [email protected] > ------------------------------------------------------------------------ > > > > Thanks Yuri! I do wonder what security implications this might have for > the policy engine where a nefarious user could trick it into performing > an action on another file via symlink hijacking. Truthfully I've been > more worried about an accidental hijack rather than someone being > malicious. I'll open an RFE for it since I think it would be nice to > have. (While I'm at it, I think I'll open another for having chown call > exposed via the API). > > -Aaron > > On 7/22/16 3:24 PM, Yuri L Volobuev wrote: >> In a word, no. I can't blame anyone for suspecting that there's yet >> another hidden flag somewhere, given our track record, but there's >> nothing hidden on this one, there's just no code to implement >> O_NOFOLLOW. This isn't Posix, and we just never put it in. This would be >> a reasonable thing to have, so if you feel strongly enough about it to >> open an RFE, go for it. >> >> yuri >> >> Inactive hide details for "Knister, Aaron S. (GSFC-606.2)[COMPUTER >> SCIENCE CORP]" ---07/21/2016 09:05:11 AM---Hi Everyone, I've"Knister, >> Aaron S. (GSFC-606.2)[COMPUTER SCIENCE CORP]" ---07/21/2016 09:05:11 >> AM---Hi Everyone, I've noticed that many GPFS commands (mm*acl,mm*attr) >> and API calls (in particular the >> >> From: "Knister, Aaron S. (GSFC-606.2)[COMPUTER SCIENCE CORP]" >> <[email protected]> >> To: gpfsug main discussion list <[email protected]>, >> Date: 07/21/2016 09:05 AM >> Subject: [gpfsug-discuss] GPFS API O_NOFOLLOW support >> Sent by: [email protected] >> >> ------------------------------------------------------------------------ >> >> >> >> Hi Everyone, >> >> I've noticed that many GPFS commands (mm*acl,mm*attr) and API calls (in >> particular the putacl and getacl functions) have no support for not >> following symlinks. Is there some hidden support for gpfs_putacl that >> will cause it to not deteference symbolic links? Something like the >> O_NOFOLLOW flag used elsewhere in linux? >> >> Thanks! >> >> -Aaron_______________________________________________ >> gpfsug-discuss mailing list >> gpfsug-discuss at spectrumscale.org >> http://gpfsug.org/mailman/listinfo/gpfsug-discuss >> >> >> >> >> _______________________________________________ >> gpfsug-discuss mailing list >> gpfsug-discuss at spectrumscale.org >> http://gpfsug.org/mailman/listinfo/gpfsug-discuss >> > > -- > Aaron Knister > NASA Center for Climate Simulation (Code 606.2) > Goddard Space Flight Center > (301) 286-2776 > > [attachment "signature.asc" deleted by Marc A Kaplan/Watson/IBM] > _______________________________________________ > gpfsug-discuss mailing list > gpfsug-discuss at spectrumscale.org > http://gpfsug.org/mailman/listinfo/gpfsug-discuss > > > > > _______________________________________________ > gpfsug-discuss mailing list > gpfsug-discuss at spectrumscale.org > http://gpfsug.org/mailman/listinfo/gpfsug-discuss > -- Aaron Knister NASA Center for Climate Simulation (Code 606.2) Goddard Space Flight Center (301) 286-2776 _______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
_______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
