I don't think this is a privileges problem but rather a name resolution issue. The ability to run dbms_snaphost has been conveyed to connect -- what connect is probably doing is not passing a fully qualified object name to refresh_tab -- hence dbms_snapshot.refresh is attempting to refresh CONNECT.snapshot_name -- which does not exist. This example shows how this works. P1 is unqualifed -- P2 has the correct schema name attached. See what happens in each case:

SQL> create snapshot foo as select * from dual;
Materialized view created.

SQL> create or replace procedure p1
2 as
3 begin
4 dbms_snapshot.refresh( 'FOO', 'C' );
5 end;
6 /

Procedure created.

SQL> create or replace procedure p2
2 as
3 begin
4 dbms_snapshot.refresh( 'OPS$TKYTE.FOO', 'C' );
5 end;
6 /

Procedure created.

SQL>
SQL> grant execute on p1 to public;

Grant succeeded.

SQL> grant execute on p2 to public;

Grant succeeded.


SQL> drop user a cascade;

User dropped.

SQL> grant create session to a identified by a;

Grant succeeded.

SQL>
SQL> connect a/a
Connected.
SQL>
SQL> exec ops$tkyte.p1
BEGIN ops$tkyte.p1; END;

*
ERROR at line 1:
ORA-23401: snapshot "A"."FOO" does not exist
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 604
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 661
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 641
ORA-06512: at "OPS$TKYTE.P1", line 4
ORA-06512: at line 1


SQL> exec ops$tkyte.p2

PL/SQL procedure successfully completed.

SQL>
SQL> connect /
Connected.