Skip to main content
Solved

Allow end-user to input file/folder path as variable

S
Forum|alt.badge.img+3

Hi all,
I'm trying to allow end-users to modify permissions on shared storage because group posix permissions are changing to read-only when they are copying/moving files/folder (preventing write permissions for the group). I'm trying to create a workaround so they can continue to collaborate until a longer term solution can be found. Currently, the script below is written to just work locally as a service/script, but running into permissions issues when run on files not owned by said user obviously - so hoping I can implement in Self Service with the user inputing the path to said files/folders so the script can run with the JSS admin credentials, and adjust the permissions appropriately without having the user to input admin credentials. Hoping self service could be a way to provide a more secure workaround, not revealing an admin password via script locally on the machine.

--

for f in "$@"
do chmod -R ug=rwx "$f" chmod -R o=rx "$f" chgrp -R "GroupName" "$f"

done

--

Any ideas if this can be accomplished? For example, a script variable whereby a user could drag a folder they want to modify into self service and it would add that as the path variable for the script?

Best answer by mm2270

Sure thing. If you run into any issues, post back. It is possible it won't run due to the script commands not running as the user. Years back on older versions of macOS this was never an issue, but as Apple began tightening the screws on security, they began to block various interaction items from running unless they ran as the logged in user. There are workarounds to that though if needed.

BTW, here is a slightly more forgiving version of this. There may be a more graceful way to handle the user canceling from choosing anything in the dialog (it has a Cancel button in it), but this will try to capture an error and set the variable to something the script can recognize as no folder chosen. Otherwise it would end up trying to loop over a non-existent selection, and generate errors.

#!/bin/bash

FOLDER_TO_PROCESS=$(/usr/bin/osascript << EOD
tell application "System Events"
activate
try
set FolderName to POSIX path of (choose folder with prompt "Please choose a folder:")
on error
set FolderName to "!ERROR!"
end try
end tell
EOD)

if [[ "$FOLDER_TO_PROCESS" == "!ERROR!" ]]; then
    echo "No folder chosen"
    exit 0
else
    echo "$FOLDER_TO_PROCESS chosen"
    ## Run your loop here, or better yet, place the loop into a function that can be called at this point
fi
View original
    Did this topic help you find an answer to your question?

    5 replies

    M
    Forum|alt.badge.img+16
    • mm2270
    • Legendary Contributor
    • 7880 replies
    • January 25, 2019

    You'd probably have to look at using Applescript's choose verb. Something like this:

    #!/bin/bash

FOLDER_TO_PROCESS=$(/usr/bin/osascript << EOD
tell application "System Events"
activate
set FolderName to POSIX path of (choose folder with prompt "Please choose a folder:")
end tell
EOD)

echo "$FOLDER_TO_PROCESS"

    You could then use "$FOLDER_TO_PROCESS" as the variable of the folder they chose to run your loop over.

    S
    Forum|alt.badge.img+3
    • skelllter
    • Author
    • New Contributor
    • 6 replies
    • January 25, 2019

    mm2270 - Thank you for your suggestion. I'm going to try implementing this as a script in self service. I will let you know the results!

    Cheers

    M
    Forum|alt.badge.img+16
    • mm2270
    • Legendary Contributor
    • 7880 replies
    • Answer
    • January 25, 2019

    Sure thing. If you run into any issues, post back. It is possible it won't run due to the script commands not running as the user. Years back on older versions of macOS this was never an issue, but as Apple began tightening the screws on security, they began to block various interaction items from running unless they ran as the logged in user. There are workarounds to that though if needed.

    BTW, here is a slightly more forgiving version of this. There may be a more graceful way to handle the user canceling from choosing anything in the dialog (it has a Cancel button in it), but this will try to capture an error and set the variable to something the script can recognize as no folder chosen. Otherwise it would end up trying to loop over a non-existent selection, and generate errors.

    #!/bin/bash

FOLDER_TO_PROCESS=$(/usr/bin/osascript << EOD
tell application "System Events"
activate
try
set FolderName to POSIX path of (choose folder with prompt "Please choose a folder:")
on error
set FolderName to "!ERROR!"
end try
end tell
EOD)

if [[ "$FOLDER_TO_PROCESS" == "!ERROR!" ]]; then
    echo "No folder chosen"
    exit 0
else
    echo "$FOLDER_TO_PROCESS chosen"
    ## Run your loop here, or better yet, place the loop into a function that can be called at this point
fi
    S
    1 person likes this
    • S
      skelllter
    S
    Forum|alt.badge.img+3
    • skelllter
    • Author
    • New Contributor
    • 6 replies
    • January 25, 2019

    mm270 - thank you so much. Saved me a lot of time. Here is the script I ended up implementing, which allows the user to select a folder to adjust permissions on without requiring admin access.

    --

    !/bin/bash

    FOLDER_TO_PROCESS=$(/usr/bin/osascript << EOD
    tell application "System Events"
    activate
    set FolderName to POSIX path of (choose folder with prompt "Please choose a folder:")
    end tell
    EOD)

    echo "$FOLDER_TO_PROCESS"

    chmod -R ug=rwx "$FOLDER_TO_PROCESS"
    chmod -R o=rx "$FOLDER_TO_PROCESS"

    exit 0

    M
    Forum|alt.badge.img+16
    • mm2270
    • Legendary Contributor
    • 7880 replies
    • January 25, 2019

    And is it running successfully from Self Service? If so, that's good to hear!

    Reply


    Most helpful members this week

    Terms & ConditionsCookie settingsAccessibility statement

    Cookie policy

    We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

     
    Cookie settings