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
